[
Lists Home |
Date Index |
Thread Index
]
Marc de Graauw wrote:
>I've got an actual project I wasn't able to do with REST in a satisfactory
>way (although I would have liked to).
>
>I have been writing a SOAP/WSDL specification for HL7v3 messages for the
>Dutch Health Authority.
>
>Those HL7v3 messages are in XML, and derived from older (v2) non-XML
>formats, so the messages themselves have a quite venerable age. As an
>example, an important class of messages is query/response. An example I've
>been working on is a query with (among others) a patient id, which gets a
>response with all medication that has been prescribed to this patient. In
>HL7v3 the queries themselves have a lot of elements. With SOAP this is not
>much of a problem: both the query and response are XML messages. With REST I
>have the following options:
>- Use GET, and translate the query to a URI. Now I have two different
>formats for query and response, and an awful long and hard-to-read URI.
>
>
I am curious: how awful long would that URI be?
I am working a lot with RT (a trouble ticket system), which provides
bookmarkable URIs even for rather complex search results. These URIs
quickly become quite long and are completely unreadable because they are
automatic serializations of (usually nested) boolean queries.
I have never experienced any problems with them nor was readability of
the URIs ever an issue. Users are just happy that they can bookmark
their searches and even get the result as an RSS feed.
Can you send an example 'input XML' for HL7v3?
----------
Besides that, I think your analysis is pretty good. It definitely
addresses one of the more problematic situations when wrapping legacy
apps with REST.
Jan
>- Use POST to send the XML query and fetch the XML response. This is not
>very RESTful, since the patient's medication history in the response is
>naturally a resource, and GET is the RESTful way to retrieve a resource. (If
>I follow this solution, I would end up using POST for all or almost all
>HL7v3 interactions. If I add an envelope and headers, I've almost got SOAP
>over HTTP.)
>- Use PUT or POST to send the query to the receiver, and have the receiver's
>server PUT or POST the response to the sender's server. Same objections as
>above apply.
>- Rewrite HL7v3 to use simpler queries which map more naturally to REST.
>Now, of course this is not something I could do on my own, and anyway, I
>believe a technology should enable me to use existing vocabularies, not
>force me to rewrite them to enable the technology. (If there had been no
>HL7v2 or v3, I believe using REST would have been an option, and a different
>design would have made using REST in a RESTful way possible.)
>
>IMHO REST just does not map easily to request/response patterns where the
>request itself is complex.
>
>Regards,
>
>Marc
>
>| -----Original Message-----
>| From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
>| Sent: woensdag 30 maart 2005 18:36
>| To: xml-dev@lists.xml.org
>| Subject: [xml-dev] What Does SOAP/WS Do that A REST System Can't?
>|
>| After all the threads on this, I can't remember ever seeing
>| this question answered. Can someone point me to a list of
>| the capabilities that one gets using
>| SOAP/WS* that one won't get using REST?
>|
>| len
>|
>| -----------------------------------------------------------------
>| The xml-dev list is sponsored by XML.org
>| <http://www.xml.org>, an initiative of OASIS
>| <http://www.oasis-open.org>
>|
>| The list archives are at http://lists.xml.org/archives/xml-dev/
>|
>| To subscribe or unsubscribe from this list use the subscription
>| manager: <http://www.oasis-open.org/mlmanage/index.php>
>|
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>
>
--
Jan Algermissen
Consultant & Programmer
http://jalgermissen.com
|
