REST and web services - having trouble understanding them

Question

Well, the title more or less says it all. I sort of understand what REST is - the use of existing HTTP procedures (POST, GET, etc.) to facilitate the creation/use of web services. I'm more confused on what defines what a web service is and how REST is actually used to make/expose a service.

For example, Twitter, from what I've read, is RESTful. What does that actually mean? How are the HTTP procedures invoked? When I write a tweet, how is REST involved, and how is it any different than simply using a server side language and storing that text data in a database or file?

Answer 1

Hey,

This concept is also a bit vague to me but after looking at your question I decided to clarify it a bit more for myself.

please refer to this link in msdn and this.

Basically it seems that it is about using http methods (Get/Post/Delete) to identify the exposure of resources the application allows. For example: Say you have the URL :

http://Mysite.com/Videos/21 

where 21 is an id of a video. We can further define what methods are allowed to this url - GET for retrieval of the resource, POST for updating/ Creating, Delete for deleting.

Generally, it seems like an organized and clean way to expose your application resources and the operations that are supported on them with the use of http methods

Answer 2

A RESTful architecture provides a unique URL that defines each resource individually and infers through HTTP action verbs the appropriate action to do for the same URL.

The best way I can think to explain it is to think of each data model in your application as a unique resource, and REST helps route the requests without using a query string at the end of the url, e.g., instead of /posts/&q=1, you'd just use posts/1.

It's easier to understand through example. This would be the REST architecture enforce by Rails, but gives you a good idea of the context.

• GET /tweets/1 ⇒ means that you want to get the tweet with the id of 1
• GET /tweets/1/edit ⇒ means you want to go to the action edit that is associated with the tweet with an id of 1
• PUT /tweets/1 ⇒ PUT says to update this tweet not fetch it
• POST /tweets ⇒ POST says i got a new one, add it to the db, i cant give an id cuz i dont have one yet until i save it to the db
• DELETE /tweets/1 ⇒ delete it from the DB

Resources are often nested though so in twitter it might be like

• GET /users/1/jedschneider/1 ⇒ users have many tweets; get the user with id of jedschneider and its tweet id 1

The architecture for implementing REST will be unique to the application, with some apps supporting by default (like Rails).

Answer 3

You may want to start with this excellent introductionary writeup. It covers it all, from start to end.

Answer 4

You're struggling because there are two relatively different understandings of the term "REST". I've attempted to answer this earlier, but suffice to say: Twitter's API isn't RESTful in the strict sense, and neither is Facebook's.

sTodorov's answer shows the common misunderstanding that it's about using all four HTTP verbs, and assigning different URIs to resources (usually with documentation of what all the URIs are). So when Twitter is invoking REST they're merely doing just this, along with most other RESTful APIs.

But this so-called REST is no different than RPC, except that RPC (with IDLs or WSDLs) might introduce code generation facilities, at the cost of higher coupling.

REST is actually not RPC. It's an architecture for hypermedia based distributed systems, which might not fit the bill for everyone making an API. In the linked MSDN article, the hypermedia kicks in when they talk about <Bookmarks>http://contoso.com/bookmarkservice/skonnard&lt;/Bookmarks&gt;, the section ends with this sentence:

These representations make is possible to navigate between different types of resources

which is the core principle that most RESTful APIs violate. The article doesn't state how to document a RESTful API and if it did so, it would be a lot clearer that clients would have to navigate links in order to do things (RESTful), and not be provided with a lot of URI templates (RPCish).