Resource-Oriented Web Services

See Resource-Oriented Web Services at its new home on bradley-holt.com.

Below are the slides from my presentation on Resource-Oriented Web Services at the September 12th, 2009 Vermont Code Camp:

Resource-Oriented Web Services

View more documents from Bradley Holt.

HTML 5, HTTP Methods & REST

See HTML 5, HTTP Methods & REST at its new home on bradley-holt.com.

Lots of very exciting things are happening right now for us web standards aficionados. The big news is the buzz around HTML 5 and its growing support in modern web browsers (modern meaning not Internet Explorer). The current state of web standards makes it difficult, but certainly not impossible, to use the web as a true application platform. HTML 5 promises to change this (maybe not fully until 2022 — but we're patient). Many articles have been written about HTML 5 but there's one tiny, but very important, feature I'd like to focus on here: support for the HTTP PUT and DELETE methods in forms. First, a little bit about REST…

I've talked about REST here before but REST is useful for more than just building web services. REST is an abbreviation for representational state transfer and is an architectural style for building software. The web itself is built using REST so it is a proven and scalable architecture. Unfortunately many web developers ignore REST to their detriment. Conforming to REST principles can help with search engine optimization (SEO) as well as make your web applications more usable (through predictability of actions) and scalable (the web itself has scaled to massive proportions).

Using a RESTful approach, every URL is a representation of a resource (a noun). These resources can then be retrieved and manipulated (have their state changed) using a standard set of verbs. These verbs are actually HTTP methods. There are a whole bunch of verbs/HTTP methods but only worry about four of them (at least for now): GET, POST, PUT, and DELETE. Here is an example of how some nouns and verbs can be used to together, borrowing from the Atom Publishing Protocol (APP):

HTTP method	URI	result
GET	/people	GETs a collection of people
POST	/people	POSTs a new person to the collection (using data in the POST request)
GET	/people/bradley-holt	GETs bradley-holt
PUT	/people/bradley-holt	PUTs an updated version of bradley-holt (using data in the PUT request)
DELETE	/people/bradley-holt	DELETEs bradley-holt

The problem was that up until now there was no way to specify a form method other than GET or POST. This meant that everything had to be tunneled through POST (or had to be done using JavaScript) which, while not technically incorrect, was incovenient and did not allow web developers to fully express the intent of user actions. HTML 5 specifies that forms can now have the methods of PUT and DELETE as well. This simple addition is one small way in which HTML 5 will allow the web to become more of a fully-feature application platform.

For you Zend Framework developers: I just learned today that Zend Framework 1.9 will include a new REST router which will help web developers adhere to RESTful principles. Please use it and also use the new PUT and DELETE methods in HTML 5 forms as browser support catches on.

It's a RESTful World

See It's a RESTful World at its new home on bradley-holt.com.

Web developers have many options to choose from when it comes to web services. These options include SOAP, XML-RPC, and REST. It is my opinion that REST will emerge as the primary web services "protocol." The advantages and disadvantages of each protocol is a topic that has been discussed to great length online. Here are the primary reasons why I think REST has the advantage:

• REST is simple. Time and time again, simple has won on the web. The web itself is successful because of its simplicity. People are really good at making things more complicated than they need to be (which is why we have SOAP).
  
• REST builds on the simple concepts that make the web work. URLs are resources/nouns that can have HTTP methods/verbs such as GET, POST, PUT, and DELETE applied to them.
• It does not dictate what the actual data will look like. This is seen as a weakness by many but why should this be the domain of the web service protocol? Here you can pick what works best for the data you are communicating. Perhaps XML defined through XML Schema, DTD, or RELAX NG is best for a particular use case. Maybe you'd prefer to use JSON instead. Maybe you simply want to use (X)HTML and microformats. Maybe you're dealing with binary data that isn't machine-readable such as images or PDFs. If it can be represented by a URL and can be gotten (GET), posted (POST), put (PUT), and/or deleted (DELETE) it's RESTful.

Here is some interesting reading on REST:

• How I Explained REST to My Wife
• Implementing REST Web Services: Best Practices and Guidelines