Comments on: REST for Corporate IT http://jeffspost.wordpress.com/2009/01/25/rest-for-corporate-it/ Jeff Staddon on Business and Technology Sun, 12 Jul 2009 17:41:26 +0000 http://wordpress.com/ hourly 1 By: PJ http://jeffspost.wordpress.com/2009/01/25/rest-for-corporate-it/#comment-906 PJ Mon, 26 Jan 2009 22:51:20 +0000 http://jeffspost.wordpress.com/?p=81#comment-906 Yes, PUT and DELETE are 'hard' to support.. but you can at least support then as extensions to POST, which is very commonly used and supported by browsers, so no extra effort. Besides, putting modification primitives behind POST is just hygenic - else a naive webcrawler can ruin your whole day. Once there was a wiki that had 'delete page' as a GET method... and it met a CEO's PocketPC 'cache this site so I can read it on the airplane' software... resulting in a very unhappy sysadmin... Yes, PUT and DELETE are ‘hard’ to support.. but you can at least support then as extensions to POST, which is very commonly used and supported by browsers, so no extra effort.

Besides, putting modification primitives behind POST is just hygenic – else a naive webcrawler can ruin your whole day. Once there was a wiki that had ‘delete page’ as a GET method… and it met a CEO’s PocketPC ‘cache this site so I can read it on the airplane’ software… resulting in a very unhappy sysadmin…

]]> By: Bob Gregory http://jeffspost.wordpress.com/2009/01/25/rest-for-corporate-it/#comment-905 Bob Gregory Sun, 25 Jan 2009 14:10:38 +0000 http://jeffspost.wordpress.com/?p=81#comment-905 I disagree with you throughout. 1) The consistency of SOAP is its only benefit - there is no agreed mechanism for service discovery in REST, and the lack of standard formats is a hindrance - not a solution to the well-known problems of SOAP. ATOMPub is emerging as an excellent standard for POX services, but JSON, while popular, has no means of defining or validating document schema and this makes *real* SOA harder to implement. When implemented properly, SOAP has a lot going for it, but implementing it properly is difficult (read up on the WSS or WSE standards - zomgwtflololol). 2) REST, lacking a formalised message structure, would almost certainly save a few bytes on the wire if you wanted to pass a "3000 character sql statement". SOAP would produce a larger message, particularly if you chose a light-weight format for your REST message. Incidentally 3000 characters isn't a large message at one byte per character. 3) Don't pass SQL statements to your web server. srsly dude. 4) Defining a service solely in terms of GET operations is *not* RESTful. It's an HTTP service, but fails to capture the basic idea of REST - that we can represent an application's state as HTTP operations over a set of uniquely identified resources. I'm not a purist by any means, I'm a dirty, filthy hacker - but a GETful service is not RESTful, it's just simple. Furthermore, REST (sometimes) tends to scale because it differentiates between operations that change resources, and operations that do not. If all your GET requests are idempotent, then you can cache hard at the application boundary. If your GET requests are really updates in disguise, then it needn't scale any better than SOAP 'cos you're still doing RPC, except that you've dropped any sense of rigour in your request/response formats. I disagree with you throughout.

1) The consistency of SOAP is its only benefit – there is no agreed mechanism for service discovery in REST, and the lack of standard formats is a hindrance – not a solution to the well-known problems of SOAP. ATOMPub is emerging as an excellent standard for POX services, but JSON, while popular, has no means of defining or validating document schema and this makes *real* SOA harder to implement.

When implemented properly, SOAP has a lot going for it, but implementing it properly is difficult (read up on the WSS or WSE standards – zomgwtflololol).

2) REST, lacking a formalised message structure, would almost certainly save a few bytes on the wire if you wanted to pass a “3000 character sql statement”. SOAP would produce a larger message, particularly if you chose a light-weight format for your REST message. Incidentally 3000 characters isn’t a large message at one byte per character.

3) Don’t pass SQL statements to your web server. srsly dude.

4) Defining a service solely in terms of GET operations is *not* RESTful. It’s an HTTP service, but fails to capture the basic idea of REST – that we can represent an application’s state as HTTP operations over a set of uniquely identified resources.

I’m not a purist by any means, I’m a dirty, filthy hacker – but a GETful service is not RESTful, it’s just simple.

Furthermore, REST (sometimes) tends to scale because it differentiates between operations that change resources, and operations that do not. If all your GET requests are idempotent, then you can cache hard at the application boundary.

If your GET requests are really updates in disguise, then it needn’t scale any better than SOAP ‘cos you’re still doing RPC, except that you’ve dropped any sense of rigour in your request/response formats.

]]>