For the last couple of decades application developers whose applications were destined for consumption via the ubiquitous web browser have struggled with and found workarounds for the fundamental limitation of HTTP - that it is a CRUD data protocol only. It has no support for the kinds of interactivity expected in many types of modern applications - event responses, adaptivity, etc. As long as all you intend to do is manually create, update and delete data HTTP is fine, beyond that come all the workarounds that have led to Web 2.0 and beyond.
Of course those capabilities come at a price - complexity, and the originator of HTTP himself is no fan of complexity. Enter ROA, invented by said originator of HTTP. Resource-oriented architecture is, put simply, a way of avoiding all the complexity that has been layered onto or worked around HTTP. You might wonder how that's possible - how can a new means of designing interfaces avoid all the complexity we've amassed in order to create dynamic, adaptive applications over a protocol only designed for CRUD? The answer is simple, of course, much like its originator - just don't write dynamic, adaptive applications! Stick to manually controlled CRUD applications and all your problems will magically go away! Within the notions that RESTful interfaces do manage to encapsulate, we find there are 3 'types' of interface that can be modeled RESTfully:
Type I: Resource Set Service
This type of services is mapped to a set of domain resources. In the online shopping scenario, resource related to a set of customers and a set of orders can be both considered of this type. We name them CustomerSet and OrderSet respectively. Type I RESTful Web services may be utilized to capture the concept level resources or the set of instance resources. This type of services support all four HTTP operations(GET, PUT, DELETE and POST).
Type II: Individual Resource Service
Individual domain resources can be modeled with this type of services that represent the individual resources in the resource set. For example, in the scenario, individual customer and individual orders are mapped to this type. Individual payment and shipment are also considered of this type associated with orders and customers. Type II RESTful Web services may be utilized to capture instance level resources, and it supports three HTTP operations(GET, PUT, DELETE). The POST operation is not applicable here since the URI identified individual resource is already created.
Type III: Transitional Service
Although most of RESTful WSs are mapped to the domain resources or resource sets, some of the services are more transition or transformation oriented. The functionality of this type of services is loosely defined as services that consume resources, create resources and update or transform the states of the related resources. For example, SubmitPayment and ShipOrder in the scenario are of this type. When we invoke SubmitPayment with the order information, we create a new resource payment associated with this order, and we update the is-Paid property, denoting the payment status, of the order resource from "false" to "true". Similar steps need to be done for the Web service shipOrder as well. Type III RESTful Web services may be utilized to capture transition-oriented functionalities, and they can only support the POST operation.
Hm, type III are "to be avoided if possible", seeing as all they are ever responsible for are unimportant services that "consume resources, create resources and update or transform the states of the related resources." Wait a second, though, isn't that precisely what most application interfaces actually do? In fact, aren't those precisely the types of actions that HTTP 1.0/1.1 didn't support particularly well, causing the invention of the entire arsenal of web application infrastructure that one can so easily get lost in today? So we have this "type III", "to be avoided", "workaround" kind of RESTful interface. i.e. we have a place to reimplement all of that arsenal of infrastructure in the last two decades that has been invented to accomplish things like consuming, creating, updating and transforming the statesof of related resources. Sure, RESTful interfaces, like web services in general, are a great way to exchange information between heterogenous systems without requiring those systems understand each others' internals. Beyond that, though ROA isn't much more than a superhighway to the past. Type III RESTful web services , notably, are known as transitional services. Is that a reference to their dealing with state transitions, or to the wishful thinking of REST's originator that eventually the world will transition to a pure CRUD based reality that he can model without having to think?
No comments:
Post a Comment