Our application is pretty UI intensive and we wanted it to have a nice, modern look and feel. As development went on, we soon found ourselves issuing a good amount of AJAX calls to the server. Without careful planning, this can soon become an unmanageable mixture of HTML, JSON and XML response formats, and dozens or hundreds of different GET and POST requests that expect various parameters.
Our architect soon tackled the issue and we decided to define a full featured REST API for the application (incidentally, we moved to Spring MVC which we found nicer), which we then access from the client side.
We have since defined dozens of URLs that handle our application requests. Much has been said about how REST method signatures should look: should resource names be used in singular or plural ? is it mandatory to use PUT and DELETE methods and do they need to be idempotent ? how do list/search methods look like ? Not to forget that there are also some well known implementations that provide default methods for most operations.
Besides, REST is not a protocol, but an application architecture style . Without an strict definition, nowadays there are many REST principles that are sistematically violated in real-world applications: not many REST APIs use hyperlinks as their only method reference (rather, they publish API documentation and expect programmers to directly access their published methods). Not all services use all four HTTP methods (GET, POST, PUT, DELETE) as defined by HTTP. Not all of them have consistent naming rules for resources.
Seeing how loose REST is about API aspect, I have collected a few examples from some of the most famouse services on the Internet, so we can have an oversight of how famous REST APIs look as of today.
Facebook (Graph API)
Facebook publish resources as a graph of social objects . Every object in the social graph has a unique ID. You can access the properties of an object by requesting:
For example, the official page for the Facebook Platform has id 19292868552, so you can fetch the object at: https://graph.facebook.com/19292868552.
Responses are JSON:
"name": "Facebook Platform",
Relationships between objects are called connections and are accessed using the name of the connection:
And results are also JSON:
"name": "John John",
"name": "Andy Andy",
You can render the current profile photo for any object by adding the suffix /picture to the object URL. They have consistent support for paging, selecting fields and/or multiple objects in one call, accepting/returning different date formats and fulltext search:
They also provide support for publishing (via POST) to the appropriate resource, using a few simple parameters. The following URL is used to add a comment to an object:
This API uses only GET and POST. They don't use hyperlinks to reference other objects (for example, lists are composed of object IDs, not URLs).
Twitter API  is also GET/POST based:
Get user home timeline, users who retweeted a post, followers:
Modifications are done via POST, like the URL used for actually tweeting:
These GET and POST methods accept a variety of parameters which are very well documented. Parameters can be used to filter the timespan of the object we want to retrieve, for defining pagination, filtering, whether to include extra metadata about objects returned... Twitter API can also provide a number of response formats: JSON, XML, RSS, Atom.
This is an example of a response list of tweets in JSON format (which is an array of tweet objects):
"created_at": "Fri Jul 16 16:58:46 +0000 2010",
Google Custom Search API
This is a very simple API . You can retrieve results for a particular search by sending an HTTP GET request to its URI. The URI for a search has the following format:
Parameters have to include the Google API key, the search query and other optional Google query parameters (response format, pagination, search options, filtering...). For example:
Response formats can be JSON or Atom.
"title": "Google Custom Search - flowers",
The big players have very different REST method signature approaches, but all of them share the simplicity and handyness of REST APIs. Being public APIs, all of them are also able to provide results in a number of formats, which allow for an easy consumption of these web services from a huge number of technologies.
As the real world rules for REST web services seem so lax, my advice is to prioritize ease of usage when designing REST services, and leverage the support that your tools or framework provide when building these services. The actual aspect of method signatures and result types is not as important as the naming and type consistency across your various method calls. Using HTTP methods properly is not as critical unless full proxy-cache support is a requirement for your system, and in many cases you'll be safe just using POST for requests that change the state of the system.