Summary of points about good RESTful API design from below talk:
Definition: Representational state transfer (REST) or RESTful Web services are one way of providing interoperability between computer systems on the Internet. REST-compliant Web services allow requesting systems to access and manipulate textual representations of Web resources using a uniform and predefined set of stateless operations
1) 2 base urls
a) for collection (/dogs)
b) for a single element (/dogs/bo)
2) POST, GET, PUT, DELETE
3) nouns are good, verbs are bad
4) Assocations GET /owners/bob/dogs
5) Complex Associations – Sweep under the carpet (behind the question mark)
6) pagination (offset, limit or start, count)
7) searching ( global: /search?q=fluffy+dog , scoped: /owners/bob/dogs/search?q=fluffy+dog)
8) versioning (as far to the left as possible)
9) give me exactly what i need
- a) /people:(id,first_name,last_name)
- b) ?fields=id,first_name,last_name
10) output format
- a) /venue.json
- b) ?output=json
11) Standardize Error Formats
12) Make dog to bark (/dog?event=bark)
- Minimize HTTP Requests
- Images : CSS Sprites are the preferred method for reducing the number of image requests. Combine your background images into a single image and use the CSS background-image and background-position properties to display the desired image segment.
- Use a Content Delivery Network
- Add an Expires or a Cache-Control Header
- Gzip Components
- Put Stylesheets at the Top
- Put Scripts at the Bottom : The problem caused by scripts is that they block parallel downloads.
- Split Components Across Domains : The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel.
- Reduce DNS Lookups : DNS lookups take time. Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the page. Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times.
- Remove Duplicate Scripts : Due to large number of developers and size of project its possible a script etc may get loaded multiple times.
- Don’t Scale Images in HTML
- Avoid Empty Image src
- Use Profiling tools to identify which parts of your code are consuming more time and more memory
- Fetch Data in Parallel : (multi curl for PHP, node.js, etc)
- Use EXPLAIN statement to analyze your SQL queries. Based on that add proper indexes
- Prepared statements in SQL need to be parsed just once
- Use Opcode Cache which will save the server from parsing your php again
- Use Memcache DB for storing frequent calls to the database
- Use MySQL Master Slave for faster read access
- See if schema needs to be split vertically or horizontally for faster access
Both cookies and sessions are available to you as a PHP developer, and both accomplish much the same task of storing data across pages on your site. However, there are differences between the two that will make each favourable in their own circumstance.
Cookies can be set to a long lifespan, which means that data stored in a cookie can be stored for months if not years. Cookies, having their data stored on the client, work smoothly when you have a cluster of web servers, whereas sessions are stored on the server, meaning in one of your web servers handles the first request, the other web servers in your cluster will not have the stored information.
Sessions are stored on the server, which means clients do not have access to the information you store about them – this is particularly important if you store shopping baskets or other information you do not want you visitors to be able to edit by hand by hacking their cookies. Session data, being stored on your server, does not need to be transmitted with each page; clients just need to send an ID and the data is loaded from the local file. Finally, sessions can be any size you want because they are held on your server, whereas many web browsers have a limit on how big cookies can be to stop rogue web sites chewing up gigabytes of data with meaningless cookie information.
So, as you can see, each have their own advantages, but at the end of the day it usually comes down one choice: do you want your data to work when you visitor comes back the next day? If so, then your only choice is cookies – if you have any particularly sensitive information, your best bet is to store it in a database, then use the cookie to store an ID number to reference the data. If you do not need semi-permanent data, then sessions are generally preferred, as they are a little easier to use, do not require their data to be sent in entirety with each page, and are also cleaned up as soon as your visitor closes their web browser.
– Transport Independant (REST requires HTTP. SOAP can work on HTTP, SMTP, etc)
– Built in Error Handling
– Only XML
– Provides good ACID Transactions.
– Exposes pieces of application logic , Exposes operations
– Enterprise level security since it supports WS-Security
– Suitable for banking applications
– Easier Learning Curve
– Efficient and Fast : Smaller message format
– Can use XML, JSON, etc
– REST gives access to named resources
A Hypertext Transfer Protocol (HTTP) 404 error, also commonly known as the 404 Page Not Found error, is a response code indicating that the client was able to reach the desired server but could not find the page or file for which it was looking. In simpler terms, the Internet browser was able to connect to the website in question, but the requested page was not found.
Every time a request is made from a client to a server, the HTTP protocol sends what is called HTTP headers with a status code. For a normal website, the status code is “200 OK,” which is the standard response for successful HTTP requests. Other status codes might be displayed if the website is redirected.
Each numeral in an HTTP 404 error means something. The first numeral “4” indicates that a client error has occurred, so the server is saying that there was an error on the client’s end, such as a typo. It also indicates that the error might not be permanent. The middle “0” indicates a general syntax error. The last “4” indicates which particular error was made out of the 400 client error group, which includes “400 Bad Request,” “401 Unauthorized” and “403 Forbidden.”
Some common terms in web application security testing:
Password Cracking: In order to log in to the private areas of the application, one can either guess a username/ password or use some password cracker tool for the same. Lists of common usernames and passwords are available along with open source password crackers. Enforce a complex password (e.g. with alphabets, number and special characters, with at least a required number of characters)
URL manipulation: Check all ranges of input variables. Dont accept values which are not needed by the application. Avoid forming dynamic variables.
SQL Injection: This is the process of inserting SQL statements through the web application user interface into some query that is then executed by the server. Escape the quotes. Use mysql_escape_string or equivalent.
Cross Site Scripting: When a user inserts HTML/ client-side script in the user interface of a web application and this insertion is visible to other users, it is called XSS. All HTML tags should be scrubbed from the variables. Dont use eval directly on any user input.
Spoofing: The creation of hoax look-alike websites or emails is called spoofing. Use identity images like the ones Yahoo! and bank websites are using so that user is confident he is logging on to the correct system.
Crumbs: To ensure user has come from a previous page in the flow and not directly.