This introduction is a stripped version of this good site
Intro
REST is an architecture style for designing networked applications. The idea behind this architecture is that simple HTTP is used to make "calls" between machines.
CRUD
Create, Read, Update, Delete are the four basic operations a system wants to perform. The idea is that RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data.
Features of REST
REST allows creating lightweight web services. The advantage of this kind of architecture is:
- Platform-independent (you don't care if the server is Unix, the client is a Mac, or anything else),
- Language-independent (C# can talk to Java, etc.),
- Standards-based (runs on top of HTTP), and
- Can easily be used in the presence of firewalls.
Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP:
- For security, username/password tokens are often used.
- For encryption, REST can be used on top of HTTPS (secure sockets).
- ... etc.
Important note
REST means Representational State Transfer. Thus, in a good REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it. The whole architecture indeed relies on a stateless, client-server, cacheable communications protocol: those are indeed the characteristics of the HTTP protocol (this is the reason for which HTTP is used with REST indeed).
As a result, using cookies is not a good REST application design, as cookies are generally used to store the state of some sessions. One should always use mechanisms on top of HTTP, as said before.
Request and Response
Just like the HTTP protocol (well, actually because of the HTTP protocol) the communication is divided between a *Request* and a *Response*.
A request is as simple as this URL:
http://example.com/api/user/show
The server will receive that request, parse the URL, and trigger the corresponding method. The method will (likely) perform a database operation, process the results, encode them (in JSON or XML), and send them back. JSON and XML are used because they are meant to present structured data.