In praise of REST

[Arien Malec]

Since Sean has decided to advocate SMTP, I thought I might put together a short case for REST (this is in my private citizen mode, not my NHIN Direct coordinator role).

1) Roy Fielding wrote a dissertation on REST. Who wrote a dissertation on SMTP? SOAP? Enough said.

2) Wouldn't you like to be a RESTafarian?

More seriously:

3) Writing a REST client is trivial. So trivial that the REST team will end up writing three:

a) A 140 line Python REST command line client where most of the code is parsing command line options

b) A 75 line Ruby REST client that presents an object oriented interface to a HISP (hisp.messages returns an Atom feed)

c) A Java client to interface with remote HISPs

Here's the Ruby code to create a new message and return the location of the newly created message.

def create_message(message)

    req = Net::HTTP::Post.new(messages_path)

    req.basic_auth(user, pw)

    req.content_type = 'message/rfc822'

    req.body = message

    res = Net::HTTP.new(@domain, @port).start { |http| http.request(req) }

    res['Location']

end

What's nice about it is that the interface is uniform. Want to create a message? POST to the resource. Get a message? GET the message id. Get status? Get the message's status resource. In SMTP, those operation are:

SMTP send

POP3 read

Distinguishing the type of a received message to interpret a MDN

4) Writing the REST server side is still pretty trivial. There are umpteen REST server side toolkits in umpteen languages, all of which are optimized for this very case. Getting the basic Rails server side together is a 2 hour task for an experienced Rails developer. The REST team got two implementations up and running before anyone else had started coding :-)

5) Because of (3) and (4), developer support and library support are highly available.

(3-5 show REST superiority over any other approach)

6) The REST approach is FAR more extensible than any other approach

a) Want to develop a web mail client? It's REST. XHR the same resources from the web client.

b) Don't like parsing RFC2822 messages in Javascript? Create a JSON representation of your message. Doesn't the API need to change? Nope, just set the Accept header to 'application/json'.

c) Discover a missing concept? Create a new resource. A good example of that is when we were discussing the S/MIME approach to mutual auth. Want to list the certificates for a user? Create a certificate resource...

d) Want to do additional services for an address? Create a new resource...

With SMTP, what you get is what you get. With SOAP, you have to add new SOAP endpoints, and the associated WSDLs. (SOAP has significant advantages over SMTP in this regard, but REST takes the crown).

7) You get the goodness of all the support infrastructure developed around http (caching, proxy servers, ETags, etc. etc., etc.)

--
Arien Malec
Coordinator, NHIN Direct
arien...@nhindirect.org
(510) 761-6473

--
You received this message because you are subscribed to the Google Groups "nhindirect-discuss" group.
To post to this group, send email to nhindirec...@googlegroups.com.
To unsubscribe from this group, send email to nhindirect-disc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhindirect-discuss?hl=en.

[Rob Savage]

I am not an expert, but am aware of PHIN-MS as transport layer. It is successfully implemented by a number of Immunization information systems (IIS) in bi-directional data exchange.

Rob Savage

Senior Database Management Specialist

Northrop Grumman

Contracted to support CDC/NCIRD/IISSB

608 233 6129

robs...@tds.net