1. What is REST?

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.

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.

  • In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

  • 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 recommendataion 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#.

50 comments:

Dr. M. Elkstein said...

Note that REST is actually used with two meanings, subtly different from each other. This can be confusing.

The pure meaning is the architectural style -- which is completely independent of HTTP and the Web. It can be used with HTTP and the Web, but it doesn't have to be.

The real-world meaning, most commonly used in the industry, is how REST is used in practice: HTTP-based, and with standard Web servers (e.g., Apache httpd) playing the part of REST servers.

Unless stated otherwise, the rest of this tutorial refers to the "real-world" usage of REST.

Unknown said...

Thanks a lot for this wonderful blog. It was lot helpful. But I'm lot confused between SOAP, RPC, XMLRPC, REST, Webservices.

Can you please clear them on this blog with clear examples of each. I don't know if there are other alternatives for SOAP. If there, please compare them.

Dr. M. Elkstein said...

Hello Mangol,

You might wish to take a look at pages 10 (ROA vs. SOA, REST vs. SOAP) and 11 (WSDL and WADL) for some answers.

The terms are often tainted, in the sense that the same term is used by different people, or in different contexts, to mean different things. Below is a very broad overview.

In general: RPC is any mechanism that allows you to execute methods remotely (although some technologies adapted that as a proper name, it's a general name for many such technologies). This includes CORBA, Java RMI, SOAP-based Web Services, and REST. Some of these systems use binary data transfer (CORBA, Java RMI), and others are text-based; some of the text-based ones are actually XML-based.

XMLRPC is a general name for any XML-based RPC system, i.e., a system where the data that passes between client and server is XML data. There are generic XMLRPC systems (Java's JAX-RPC comes to mind) but when discussing XMLRPC, the key technology is SOAP-based Web Services.

Web services is a generic name for web-based RPC. This includes SOAP-based web services, which normally go by the proper name "Web Services"; but now, REST is also considered a web-service architecture.

SOAP is an XMLRPC web service, i.e., a web-based RPC that uses XML for data transfer, and more specifically, it uses the SOAP data format (an XML schema) for the queries and their replies.

REST is a non-XML-based, web-based RPC; but it is also a design philosophy and architecture. Read this tutorial site for more details.

Unknown said...

Good introduction to ReST. Read the whole thing, just could not stop in between :)

pavan said...

Thanks a lot for the tutorial, i just read few pages but surely finish the whole. I am one of the kind who like to read paper as a whole and printable document. Is there anyway that i can download and read not sitting before my laptop.
thanks,
pavan.

Dr. M. Elkstein said...

Hello Pavan,

I'm sorry, but at the moment Blogger (the platform I'm using to publish this site) does not support this printing-as-a-whole feature.

pavan said...
This comment has been removed by the author.
pavan said...

thanks for the Reply Dr.M.Elkstein...actually i am doing my masters thesis on REST and SOAP. I also ready some papers, i stuck at the update in REST. Is it ok, if i ask you some doubts- only if you are comfortable.

Your Document is really interesting and nice . Thanks one more time.

Dr. M. Elkstein said...

Hello again Paven,

Please send your comments to me by email. I'll reply only if I can, though.

KeepingItSimple said...

Thanks for a very simple introduction post of ReST.

This was AWESOME.

Unknown said...

Can you please provide a single document for this site (PDF etc)?

Its awesome.

Unknown said...

Excellent tutorial.

I am starting to learn about the Open Services for Lifecycle Collaboration (OSLC) and REST is one of the 3 columns of the description.

I am the developer in charge of the installation of the Rational Team Concert product, it is just a great tool to collaborate using REST.

I will recommend this page to all my partners.

Unknown said...

How do I contact Dr. M. Elkstein? I may have a project for him.

thanks!

Dr. M. Elkstein said...

Hello casey,

Thank you, but I am happily employed at the moment.

vbmade2000 said...

Very nice tutorial about REST.
Thanx Dr. M. Elkstein for posting such nice tutorial.

Unknown said...

Yesterday I started looking for some information about RESTful. I read many blogs and tutorials, but this was the most liked, what made ​​me understand the big picture.

Thank you for sharing your knowledge

Unknown said...

'Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.'

I hope by this stement you are not implying a 1-1 mapping of POST/GET/PUT/DELETE to CRUD.

Dr. M. Elkstein said...

Hello Scott,

Not all all. No such mapping was implied, and if anything of the sort can be understood from my text, it's a simple misunderstanding. REST does use HTTP for all CRUD operations, but more often than not, only GET and POST are used.

JOBBER said...

Really nice articles.. Thanks a lot

Murali said...

Thanks for Posting a high Level overview of the Rest Architecture , i am hearing it lot nowadays.

I am working on the WEbservices with soap UI , onc quick question can Rest be used cross platform
like can we call a Java Api and then a Dot net service ..

just a thought...

Murali said...

A Very Neatly written write up for Rest

Dave said...

Dr Elkstein,

Nice tutorial! Short, clean, and clear...or as my linear programming professor used to say "Terse and Pithy". :)

Thank you!

yoda said...

Very nicely explained...good work !
Like Bruce Eckel in Java, you also manage to explain things clearly and simply. I'm sure a lot of beginners will benefit.

Grey said...

Nice blog.

How would you do internationalization (i18n) with REST? In the SOAP world, there is WS-I18N (W3C Working Draft, dated April 2008). What is available for REST?

Sandeep Meher said...

Hi Dr.M.Elkstein,
Thanks for this fantastic tutorial! I had gone through numerous articles but this series is the most practical for starting with REST.
Regards,
Sandy

Saurav Shrestha said...

Dr Elkstein,

Thank you for writing this tutorial. I'm just getting started with REST and have been tearing up my hair as to how to use it and with your posts as guidance I have successfully set it up.

Once again thank you for your help.

Unknown said...

Thanks for such a introduction of REST. It really help me a lot

Unknown said...
This comment has been removed by the author.
Unknown said...
This comment has been removed by the author.
Praveen said...

Hi Dr.M.Elkstein,

I've just started learning REST. Can we create an enterprise web application using REST along with node.js? If so, how? how secure? how scalable? how reliable? how efficient?

Regards
Praveen

Dr. M. Elkstein said...

Hello Praveen,

JavaScript in server output assumes that the output is being viewed in a browser, with JS execution capabilities. I assume the same is true for Node.js (with which I'm not really familiar). But REST does not make this assumption; in fact, the normal assumption in REST is that the output is non-interactive, informational data. (The one huge exception is the Web itself, which can be described as the canonical REST application. But I'm assuming you're thinking about something else.) So, writing a REST application with Node.js is probably inappropriate.

Anjith kumar Paila said...

Thank you very much for your article. Appreciate it.It is very useful for a novice to REST.

Tom Tobin said...

Thank you, so much, Dr. Elkstein, for this wonderful tutorial. I've read several others, but yours is the first to make things clear, and to get me functional. Much appreciated!!!

Unknown said...

Thanks for the good explanation.

Regarding the method DELETE, looks most of us read resource id from URL directly e.g. DELETE /resource/item01

Considering deleting lots of resource one time, can we read a list from request content and then delete them? in this way, resource will be specified in content.

Thanks.

G said...

thank you, thank you thank you

Dr. M. Elkstein said...

Zou Panxia: Of course this can be done. It's simply a question of API design, and the design you suggest (for "batch delete") could make sense in some contexts.

codepro said...

I'm new to programming. is there a prerequisite recommended to learning ReST. i only have basic JS knowledge at the moment.

Dr. M. Elkstein said...

"codepro", if you're new to programming, you shouldn't do system architecture... In particular, you're most likely using JS client-side, REST is normally a system-wide architecture and depends on server-side implementation.

Unknown said...

Hi Dr. Elkstein,
I enjoyed reading your blog and was wondering if you were interested in a small contracting job.

I manage a development team at a major university and we needed someone to review / audit our implementation of a RESTful service.

Do you have an email address or phone number I could contact you on ?

Thanks,
Taz

Dr. M. Elkstein said...

Hello Taz,

Thank you for your kind words. Sadly, I am unavailable for contracting jobs at the moment, given the nature of my current employment.

andy said...

thanks for your exciting explanation of REST, it helps me a lot.

Unknown said...

REST made easy! Thank you

Anonymous said...

Simple explanation about REST. Thanks for share

mejustme said...

Since the rest deals with real-world REST, can you talk a little more about the pure meaning? If it is independent of HTTP, what is it about?

Dr. M. Elkstein said...

Hello "mejustme",

From the REST point of view, HTTP is just a means of communication. Whenever you create a client/server architecture, you can decide to use REST as your design guideline: in particular, servers maintain no per-client state, and the state is sent by the client with every request; each request is entirely standalone. And you can then implement this using whatever communications protocol you wish, using non-HTTP over TCP/IP or, in fact, not even using IP at all.

This was generally known in the past as "stateless server design", though the work on REST refines and better defines the concept, best practices, etc. In practice, the term REST is used almost exclusively for scenarios with HTTP over TCP/IP.

Vishal said...

Thanks for a simple but useful article.

Unknown said...

I have gone through many blogs but this blog is very nice and easily understood. Appreciate your efforts.

Unknown said...

Really helpful Elkstein

geoffrey lund said...

I have found the tutorial on this site a great explanation of ReST for my students. I posted the URL of the site on their tutorial notes. At my University your site is blocked by Websense. Do you know why?

Dr. M. Elkstein said...

Geoffrey Lund: I do not know why this happens; I checked with the Websense (Forcepoint) company website and there is no indication of any issue. Their recommendation is that you reach out to your University IT department and ask them to update their lists or manually unblock this URL.