Stefan Tilkov wrote:
> On Nov 24, 2006, at 9:15 PM, Dennis Sosnoski wrote:
>
>> I agree completely, Paul. POX is clearly the significant alternative to
>> SOAP, and REST only has as much mindshare as it does because people
>> mistakenly consider any use of XML over HTTP as REST.
>
> Again, I'm unsure what definition of POX you're using here - POX can
> be RESTful or not.
POX *can* be RESTful, but rarely is. The vast majority of POX-type
services I'm aware of (going back to well before SOAP) are based on
exchanging XML documents and don't really care much about the transport
(though most use HTTP for this purpose, with POST to send the data to
the service and get back an XML response irrespective of whether there's
any state change on the server at all). In particular, the only use they
make of URIs is a URL to identify the service endpoint (a servlet in
Java, or a .aspx in .Net).
> ...
>>
>> I've yet to see any examples of using REST for real service
>> applications. The big problem here is that almost any reasonable service
>> is going to involve coordinated state changes to many different
>> "resources". REST appears incapable of dealing with this type of
>> requirement.
>>
>
> That's funny because I actually believe that's pretty much what it's
> built and being used for :-)
Then let me ask you how to structure an example as a REST service,
Stefan. Many of my clients are in travel-related fields, so one example
I've used in the past is an airline flight reservation. When making a
reservation there are a number of different resources involved. First
off there's the flight itself, which changes state in terms of the
number of seats booked. There's also associated information about who
has booked the seat, and some form of identifying number. Separately,
there's the reservation itself, which is typically in the realm of a
travel agency or some other form of agent. This includes payment
information, and as part of the reservation service processing there may
need to be a charge processed against the customer's credit card.
There's also often (but not always) a specific seat that's been reserved
(which is perhaps the most concrete example of a resource in this example).
So as sort of a base case we've got at least three different sets of
resources involved in a reservation service:
1. The flight itself, which is under the control of the airline; the
reservation information here needs to include passenger
information (name, address, contact information, passport #, date
of birth, etc.) as well as a reference and identifier for the
entity that originated the reservation. The reservation may or may
not include a specific seat, or general seat preference (e.g.,
window).
2. The agency system, which needs to have the reservation associated
with a particular customer account, and linked with the identifier
used by the airline for the reservation.
3. The passenger's credit card, which needs to be debited for the
amount of the reservation with funds transferred to the agency.
How would you go about structuring this as a RESTful service?
- Dennis
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
