Basic REST principels

REST is a simple way to organize interactions between independent systems. REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used. The five key principles are:

• Give every “thing” an ID
• Link things together
• Use standard methods
• Resources with multiple representations
• Communicate statelessly
  

Give every “thing” an ID

Everything that should be identifiable should obviously get an ID on the Web, there is a unified concept for IDs: The URI. URIs make up a global namespace, and using URIs to identify your key resources means they get a unique, global ID. The main benefit of a consistent naming scheme for things is that you don’t have to come up with your own scheme you can rely on one that has already been defined, works pretty well on global scale and is understood by practically anybody.  

Link things together

<order self='http://example.com/customers/1234' > 
   <amount>23</amount> 
   <product ref='http://example.com/products/4554' /> 
   <customer ref='http://example.com/customers/1234' /> 
</order>

we can easily imagine how an application that has retrieved it can “follow” the links to retrieve more information. This would be the case if there were a simple “id” attribute adhering to some application-specific naming scheme, too — but only within the application’s context. The beauty of the link approach using URIs is that the links can point to resources that are provided by a different application.

links are useful way to make an application dynamic.

Use standard methods

Set of standard methods includes GET,POST,PUT, DELETE, HEAD and OPTIONS.

GET supports very efficient and sophisticated caching, so in many cases, you don’t even have to send a request to the server. You can also be sure that a GET is idempotent — if you issue a GET request and don’t get a result, you might not know whether your request never reached its destination or the response got lost on its way back to you. The idempotence guarantee means you can simply issue the request again. Idempotence is also guaranteed for PUT (which basically means “update this resource with this data, or create it at this URI if it’s not there already”) and for DELETE (which you can simply try again and again until you get a result — deleting something that’s not there is not a problem). POST, which usually means “create a new resource”, can also be used to invoke arbitrary processing and thus is neither safe nor idempotent.

Resources with multiple representations

Provide multiple representations of resources for different needs. For example, Using HTTP content negotiation, a client can ask for a representation in a particular format:

GET /customers/1234 HTTP/1.1
Host: example.com 
Accept: application/vnd.mycompany.customer+xml  

The result might be some company-specific XML format that represents customer information. If the client sends a different request, e.g. one like this:

GET /customers/1234 HTTP/1.1
Host: example.com 
Accept: text/x-vcard 

The result could be the customer address in VCard format.

Communicate statelessly

In REST, stateless means that there is no client session data stored on the server. The server only records and manages the state of the resources it exposes. If there needs to be session-specific data, it should be held and maintained by the client and transferred to the server with each request as needed. A service layer that does not have to maintain client sessions is a lot easier to scale, as it has to do a lot fewer expensive replications in a clustered environment.