- A WOA is not a SOA because it is not description oriented. Without a description language such as WSDL, publishing and subscribing to services becomes problematic.
- A WOA is not REST because it does address “state transfer” part of REST. While I can see WOA works well in many simple cases of web application design, I believe it needs to be complement with, yes, traditional SOA, and semantic web technologies to solve complex problems, for one simple reason: not all service interactions can be modeled as CRUD.
Let’s take a very simple example: travel reservation. Let’s assume that the travel agent has implemented a WOA style service. So a client (any client on the web) can create a Reservation (Resource identified by a URI) through a simple HTTP PUT. Let’s say the Reservation is “on hold” initially. And a representation (let’s assume XML) of the Reservation is return to the client:
<reservation xmlns="…">
<flight>UA989</flight>
<date>2009-04-01Z</date>
<status>Held</status>
</reservation>
Now, maybe a day later, the client wants to purchase this reservation. What should it (since the client is not a human being in our case) do? The logical options are
1. Do an HTTP POST with a new Reservation.
<reservation xmlns="…">
<flight>UA989</flight>
<date>2009-04-01Z</date>
<status>Purchased</status>
</reservation>
But the problem is how we can ensure that the user does not change other parts of the reservation like Flight. If the answer is the system simply ignores the Flight information on a POST, how can we make that constraint known to any client on the web?
2. Do a partial update, in which case you probably need to define a whole protocol like WSRT
3. Make the Status a separate Resource. So, you would do
POST /Reservation/20090401UA989_1234/Status HTTP/1.1
… …
Purchased
The problem here is how does the client extract information about the link between resources /Reservation/20090401UA989_1234 and /Reservation/20090401UA989_1234/Status from the representation of the Reservation as, per Fielding,
A REST API should be entered with no prior knowledge beyond the initial URI
(bookmark) and set of standardized media types that are appropriate for the
intended audience (i.e., expected to be understood by any client that might use
the API). From that point on, all application state transitions must be driven
by client selection of server-provided choices that are present in the received
representations or implied by the user’s manipulation of those representations
Of course we can bring RDF in to solve this, but it is not clear how semantic web fits in the WOA stack.
