Defining a RESTful Framework

Web application frameworks have varying support for the concepts behind Representational State Transfer (REST). Most web application frameworks, if not all, allow you to create “fully” RESTful web applications. However, there does not seem to be a focus on explicitly applying RESTful principles. So, here are the key concepts that I’d like to see addressed:

  • Embrace, and don’t abstract, the Hypertext Transfer Protocol (HTTP).
  • Focus on entities/resources—identified by full Uniform Resource Identifiers (URIs).
  • Use HTTP methods (GET, POST, PUT, DELETE, OPTIONS, HEAD) to perform operations on entities/resources.
  • Allow for self-described messages through the use of header fields, such as Accept and Content-Type.
  • Make hypermedia controls a core concept (perhaps using PHACTOR as a starting point), not just a byproduct of rendering.
  • Think of web applications as state transition systems. Representations of entities/resources are states, and hypermedia controls define the available state transitions.


  • Interoperability: Focusing on open standards allows for easier integration with other systems.
  • Cacheability: Embracing HTTP gives you many caching options, almost for free.
  • Testability: Self-contained and self-describing messages are very testable. Decomposing a complex system into states and available state transitions greatly reduces the complexity of the system and its tests.

One Comment

  1. Posted August 19, 2011 at 1:55 pm | Permalink

    It’s funny you made this post. I was just talking about this a lunch. I have a side project I have been working on to do just that, embrace HTTP instead of ignore it. I can’t believe (in PHP at least) that after all of these years there isn’t a single framework that uses what HTTP already gives us in terms on content negotiation, etc.

    I am starting a framework for just this case, RestPHP. It is made to simplify the creation of RESTful web services by applying a resource oriented architecture. Each resource class can respond to each of the HTTP methods and will automagically respond with a view subclass that matches the client’s Accept header. It’s isn’t even functioning yet but it’s on GitHub. I’ll start working on it again once I get my beta android app out since it will eventually need to use the service.