It is very simple, but needs the patience.
REST is an acronym standing for Representational State Transfer, a software architecture used for developing stateless web services. The most common use of REST is on on the Web with HTTP being the only protocol used here. And the only operations allowed are the HTTP – GET (Read), PUT (Update), POST(Create) and DELETE (Delete).
The operations are like sql resource.
The main features and constraints of REST architectural style are:
Client-Server: A clear separation concerns is the reason behind this constraint. Separating concerns between the Client and Server helps improve portability in the Client and Scalability of the server components.
Stateless: All REST resources are required to be stateless. The idea is that the application would be resilient enough to work between server restarts. However, it is not uncommon to see some RESTful web services save states between requests.
Caching: Caching is allowed, however it is required that “response to a request be implicitly or explicitly labeled as cacheable or non-cacheable”
As there is no interface definition (like in SOAP), it becomes mandatory for a Client and Server to have a mutual understanding of the messages being transmitted between them.
You may want to see the pear package HTTP Request for making REST calls, which among many things supports GET/POST/HEAD/TRACE/PUT/DELETE, basic authentication, proxy, proxy authentication, SSL, file uploads and more. Using this package, I got started on a simple wrapper class called RESTclient, which gives intuitive support for making REST resource calls.
Explaining the REST by code is coming soon...
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment