Comments on: REST http://solutions.treypiepmeier.com/2006/09/28/rest/ So I don't have to figure things out more than once. Thu, 03 Jul 2008 23:05:03 +0000 http://wordpress.org/?v=2.5.2-alpha By: Dan http://solutions.treypiepmeier.com/2006/09/28/rest/#comment-7438 Dan Thu, 06 Dec 2007 14:16:21 +0000 http://solutions.treypiepmeier.com/2006/09/28/rest/#comment-7438 <p>No, it's about using the web protocols correctly. For years, people pretended that HTTP is just a way to make Remote Procedure Calls. For example:</p> <p>http://example.com/cgi_program.pl?id=3334&dir=foo&cmd=bar</p> <p>This has a lot of problems:</p> <ul> <li>It's not technology independent. What happens when you switch from Perl to Ruby on Rails?</li> <li>It's impossible to tell if "cmd=bar" is destructive or not. This affects people trying to cache the results, and affects your error retry strategy.</li> <li>It's legal for anyone to switch the order of parameters, so the document has multiple URLs. This affects the efficiency of the cache.</li> </ul> <p>Instead, it's better to put your "resources" (documents, people, whatever) at the center. This isn't any more difficult to write (at most, one extra config line in your web server, but usually not even that.)</p> <p>http://example.com/doc/foo/3334</p> <p>If you follow REST, this means:</p> <ul> <li>Doing a GET from this URL will never affect the data, so it's safe to cache. It's also idempotent, which means it's safe to restart if there was an error.</li> <li>If we want to replace the data, we can do a PUT. To alter the data, we can do a POST. Caches along the way can easily sniff for POST/PUT and realize the document has probably changed.</li> <li>You could easily make a read-only version of your private app by having a firewall allow only GET requests.</li> <li>The resource (document) has a single URL. This helps later on, when someone builds a mash-up and wants to refer to your documents.</li> </ul> <p>That's just scratching the surface. There's a lot more to it. It's one of those "things get simpler if you give yourself some limitations". For example, it might be useful to have a 10ft wide car, but the problems driving down the road would outweigh the benefits.</p> No, it’s about using the web protocols correctly. For years, people pretended that HTTP is just a way to make Remote Procedure Calls. For example:

http://example.com/cgi_program.pl?id=3334&dir=foo&cmd=bar

This has a lot of problems:

  • It’s not technology independent. What happens when you switch from Perl to Ruby on Rails?
  • It’s impossible to tell if “cmd=bar” is destructive or not. This affects people trying to cache the results, and affects your error retry strategy.
  • It’s legal for anyone to switch the order of parameters, so the document has multiple URLs. This affects the efficiency of the cache.

Instead, it’s better to put your “resources” (documents, people, whatever) at the center. This isn’t any more difficult to write (at most, one extra config line in your web server, but usually not even that.)

http://example.com/doc/foo/3334

If you follow REST, this means:

  • Doing a GET from this URL will never affect the data, so it’s safe to cache. It’s also idempotent, which means it’s safe to restart if there was an error.
  • If we want to replace the data, we can do a PUT. To alter the data, we can do a POST. Caches along the way can easily sniff for POST/PUT and realize the document has probably changed.
  • You could easily make a read-only version of your private app by having a firewall allow only GET requests.
  • The resource (document) has a single URL. This helps later on, when someone builds a mash-up and wants to refer to your documents.

That’s just scratching the surface. There’s a lot more to it. It’s one of those “things get simpler if you give yourself some limitations”. For example, it might be useful to have a 10ft wide car, but the problems driving down the road would outweigh the benefits.

]]>