REST stands for Representational State Transfer. The term was introduced
by Roy Fielding in his doctorial dissertation. REST is an architectural style
for designing networked applications. It is an alternate to using complex
mechanisms like COBRA, RPC, and SOAP to connect between client and server. REST
makes communication between remote computers easy by using the simple HTTP
protocol which support for CRUD (Create, Read, Update, and Delete) operations
on the server. In a way, our World Wide Web is also based on the REST
architecture.
In a nutshell, REST is based on the representation of resources. A
resource is an object that we can access over the World Wide Web. It can be a
document, an image, or anything. When we request a resource (an object) from a
server, the server returns the representation of that resource. In REST
architecture, a client requests an operation (CRUD) on an object (resource) on
the server, and the server returns data as per requirements.
Example – Let us consider a Web Service that returns Employee
information. The Web Service responds to client calls by polling a database and
returning a result. In classical Web Services or WCF Services, we would have a
method exposed to clients, like GetEmployee(). The REST architecture is
different from this as it does not work with the methods but with nouns
(resources / objects) and allow verbs (HTTP Methods) to operate on them.
So if we want to get Employee information, we send an HTTP GET on the
object Employee rather than query a method like GetEmployee(). The advantage is manifold, the most important
being the power and flexibility that we get in our hands to play around with
the object.
For further reading, see the References section at the end of the
article. I will not go into the details of explaining REST, rather concentrate
on how to code one from scratch.
Why use REST?
Let us consider a practical example. Imagine that you have to build a
Web Service which should be cross functional and should be able to be consumed
by any client. Traditional Web Services in .NET have to be consumed using a
proxy. What if the client does not know how to create a proxy? Imagine that
your Web Service needs to be consumed by a client running on an iPhone or
Android. As far as I know, Objective C does not know how to create a proxy. It
only knows to send basic HTTP verbs – GET, PUT, POST, and DELETE – to the
server and expect XML or string as response. Enter the world of REST!!
HTTP verbs
At this time, it is worthwhile to revise our basic HTTP verbs. I will
just give a brief introduction. Detailed information is easily available over
the internet.
GET – GET is one of the simplest HTTP methods.
Its main job is to ask the server for a resource. That resource may be an HTML
page, a sound file, a
picture file (JPEG) etc. We can say that GET method is for getting something
from the server. In GET method, the data we send is appended to the URL.
Example:
GET /path/file.html HTTP/1.0
From: someuser@jmarshall.com
User-Agent: HTTPTool/1.0
POST – The POST method is used to submit data to
be processed (e.g., from an HTML form) to
the identified resource. The data is included in the body of the request. This
may result in the creation of a new resource, or the updates of existing
resources, or both.
Example:
POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
home=Cosby&favorite+flavor=flies
PUT – The PUT method is used to submit data to be
updated (e.g., from an HTML form) to
the identified resource. Like the POST method, the data is included in the body
of the request.
DELETE - The DELETE method is used to delete a
specific resource.
No comments:
Post a Comment