REST for Corporate IT

REST is old news for web based companies, but it’s penetration into corporate IT is just beginning. SOAP has three big advantages for the corporate developer—familiarity, tool set support and ease in handling large input sets. Want to pass a 3,000 character SQL statement to a web server? SOAP swallows it up without blinking.

The consistency of SOAP however is its undoing.  Whether it’s a huge, complex sets of “simple” data or a tiny status query a SOAP service requires essentially the same infrastructure.  REST tends to scale. A simple REST service is simple.  That is a pretty compelling advantage.  It’s convenient to pop-up a web browser and see what’s going on—try that with SOAP.

To the purist out there—sorry, I don’t think the HTTP methods (GET, POST, PUT, DELETE) are going to catch on. Using anything but GET kills the “web browser as development tool” advantage and it’s just too easy to define URLs with an embedded “get” or “delete”. But if you’re willing to let that slide REST will have a nice future in Corporate IT.


Note on this Post:

Joel Arthur Baker in Paradigms: The Business of Discovering the Future discusses how shifts between patterns of thought (paradigms) create significant opportunities. Software development has historically been a pace where paradigm shifts are common–but today it seems we are seeing more than ever.  This post is one of a series discussing some of these paradigm shifts.


2 Responses to “REST for Corporate IT”

  1. Bob Gregory Says:

    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.

  2. PJ Says:

    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…

Leave a Reply to PJ Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: