REST (representational state transfer) is a process for getting information content from a Web site by reading a designated Web page that contains an XML (Extensible Markup Language) file that describes and includes the feasible content.
For example, REST could be used by an online publisher to make syndicated content available.
Periodically, the publisher would prepare and activate a Web page that included content and XML statements that described the content.
Subscribers would need only to know the URL (Uniform Resource Locator) for the page where the XML file was located, read it with a Web browser, interpret the content data using the XML information, and reformat and use it appropriately (perhaps in some form of online publication).
Now question is that why doesn't the REST programming section include any code? It is largely because REST is more about a mindset rather than code, more about design than implementation.
It may look simple, but there are few vital points to keep in mind while developing applications in the REST style.
Think about the business problem in respect of resource manipulation rather than Application programming interface design.
Enabling web services requires making data available for use by applications without knowing ahead of time exactly how that data will be used.
Start by modeling the persistent resources that is to be exposed.
There must have a single, unambiguous, authoritative identity within a system in order to identify all the conceptual entities that the system exposes as resources and to assign a unique URL to each of them.
In case of temporary resource you should be very careful if you plan to use them only as a temporary resource.
Publicly exposed resources should be sorted out that are immutable by the client and those are mutable.
Putting and deleting should be used in appropriate manner.
Proper methods should be implemented that will allow both sender and receiver to make the absolute minimum of assumptions as to the other's state.
Single logical operation should not be implemented when there are multiple requests.
Applications that need to be expects, accepts and returns should be properly documented.
A good specification of the representational schema of both mutable and immutable resources with a formal mechanism should be there (for example, XML Schema, DTD, Schematron, or RelaxNG).
There should be a proper description and documentation of the resources that can be accessed by using a "gradual unfolding methodology" to expose data for clients.
Proper linking to other related resources in every representation to enable clients to drill down for more information should be there.
You should know how to use the software to setup a server that can do content negotiation, authentication, authorization, compression, caching, vacuuming and house cleaning.
A proper abstractions should be there so the implementation can be carried out in a good way.
If there is abstractions then it can survive the storm of change from different implementations and new technologies.