Then I started web development (using PHP) one of the first things I learned was the differences between GET and POST. Back then (in 1999) GET was usually described as bookmarkable, parameter-length/payload-size is limited and post as arbitrary sized payload (parameters), not bookmarkable.
It seems that as time passed by many developers eigther completely forgot or never learned about the other verbs HTTP is offering (PUT, DELETE, HEAD, TRACE, OPTIONS, CONNECT). Instead of using HTTP as indent by the it’s makers, we added new layers on top (e.g. XML-RPC and SOAP) to practically duplicate the already build in functionality.
With the current strive for simplicity (using JSON instead of XML, Ruby on Rails instead of JSP) some developers rediscovered the Representational State Transfer (REST) architectural style. The basic ideas are simple and most of the time this functionality is exactly what we need:
- An URI describes the location of a resource.
- By using the correct verb in an HTTP-Request, resources can be retrieved (GET = read ) and manipulated (POST = create ,PUT = update, DELETE = delete)
- A resource have one or more representations (e.g. formatted as JSON, XML or HTML)
Now it’s your turn to rescue the web! Use REST, use GET if you want to retrieve resources without changing it’s state and make sure that you don’t use POST, PUT, DELETE to retrieve data. Oh, and it might also help to take a closer look an HTTP itself. Try to log some of your HTTP-traffic while surfing using a tool like wireshark and see yourself what is actually send. Some of the information (e.g. Content-Type, Cache-Control, Content-Language) might be really useful then developing a nice web application.
Further reading on this topic:
- The power of the URL-line by Jon Udell
- Show Me the Code by Joe Gregorio
- Putting REST on Rails by Dan Kubb
- Implementing REST Web Services: Best Practices and Guidelines by Hao He