What are RESTful Web Services?

REST stands for REpresentational State Transfer . REST defines a set of architectural principles by which you can design Web services that focus on a system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages. REST was first introduced by Roy Fielding in year 2000. REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines. It should be used if it is very important for you to minimize the coupling between client and server components in a distributed application . This may be the case if your server is going to be used by many different clients that you do not have control over. It may also be the case if you want to be able to update the server regularly without needing to update the client software. REST asks developers to use HTTP methods explicitly and in a way that's consistent with the protocol definition. This basic REST design principle establishes a one-to-one mapping between create, read, update, and delete (CRUD) operations and HTTP methods.
  1. Create - POST
  2. Update - PUT
  3. Retrieve - GET
  4. Delete - DELETE

Advantages of REST

A primary benefit of using REST, both from a client and server's perspective, is REST-based interactions happen using constructs that are familiar to anyone who is accustomed to using the internet's Hypertext Transfer Protocol (HTTP). An example of this arrangement is REST-based interactions all communicate their status using standard HTTP status codes . So, a 404 means a requested resource wasn't found; a 401 code means the request wasn't authorized; a 200 code means everything is OK; and a 500 means there was an unrecoverable application error on the server. example REST is using the various HTTP methods (mainly GET/PUT/DELETE ) to manipulate data. Rather than using a specific URL to delete a method (say, /user/123/delete), you would send a DELETE request to the /user/[id] URL, to edit a user, to retrieve info on a user you send a GET request to /user/[id].

Create a user with three properties:

POST /user fname=John&lname=Doe&age=25

The server responds:

200 OK Location: /user/123

In the future, you can then retrieve the user information:

GET /user/123

The server responds:

200 OK <fname>John</fname><lname>Doe</lname><age>25</age>

To modify the record (lname and age will remain unchanged):

PATCH /user/123 fname=Johnny

To update the record (and consequently lname and age will be NULL):

PUT /user/123 fname=Johnny
Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture . REST is not a "standard". There will never be a W3C recommendation for REST, for example. And while there are REST programming frameworks , working with REST is so simple that you can often "roll your own" with standard library features in languages like Perl, Java, or C#.