If you are planning to use REST in your projects, I strongly recommend you to get in touch with it’s principles. As REST makes excessive use of the standard HTTP protocol, aspects like caching can be delegated to one of the various HTTP caching products.

Below, you can find some very useful articles about the principles of REST including versioning and common mistakes when implementing a REStful service.

• http://blog.steveklabnik.com/2011/07/03/nobody-understands-rest-or-http.html
  “Let’s talk about a few cases where either REST or HTTP (which is clearly RESTful in its design) solves a common web development problem.”
• http://blog.steveklabnik.com/2011/08/07/some-people-understand-rest-and-http.html
  “As it turns out, there are two companies that you’ve probably heard of who have APIs that are much Twilio and GitHub. Let’s take a look at GitHub first.”
• http://www.infoq.com/articles/webber-rest-workflow
  “How to GET a cup of coffee on InfoQ. It describes the process of ordering a coffee at Starbucks as a RESTful protocol. This goes beyond the typical “everything is a resource” REST introductory article and focuses on HATEOAS. Highly recommended.”
• http://www.zienit.nl/blog/2010/01/rest/hateoas-by-example
  “Hypermedia as the Engine of Application State (HATEOAS) is a very useful concept in the RESTful architectural style. The best way to show the benefits of HATEOAS is by giving an example.”
• http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
  “What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.”

After having read all of those articles, you may have a more precise understanding of what RESTful interfaces should look like and what advantages you have due to the fact that it is based on HTTP.