Archive for the 'ReST' Category
The Rise of REST! Iâ€™ve noticed an increasing number of â€œWhat is REST?â€, or alternatively, explanations of REST appearing lately. Most attempt to compare REST to SOAP which is basically the wrong argument. SOAP and REST cannot be directly compared, though for the last seven years it has been. Keep in mind that REST does not mean exclusively HTTP. Just take a look at the Java content-management standards JSR 170 and JSR 283 for an example of an API based on REST using Java.
Before I attempt to put my own spin on what and why you would use REST; If you are interested at all on Software Architecture, then I highly recommend that you take the time to read Royâ€™s dissertation â€“ maybe even twice. It is a tour-de-force of what Software Architecture is. And if you feel really brave read Rohitâ€™s companion dissertation.
Why base your software architecture on REST?
The high-level answer: When you don’t “own” each component along the wire it is important that each component be allowed to evolve independently. What matters in this context is the ability to work with components at different levels of implementation. That means constraining the interface to a commonly agreed standard so every component along the wire can understand what it means to GET, PUT, POST, DELETE etc.
Secondly no matter how fast the wire becomes we are still constrained by the speed of light i.e. there will always be latency. To combat this you end up using a course grained Document-Centric mode of interaction – sending HTML/XML/JSON documents etc – instead of a fine grained Control-Centric mode. The latter is RPC the former REST.
To make sure that each component knows what is being talked about it needs to be identified. Hence URIs identify a Resource. Response meta-data describes the context of the document that was returned. [in REST terms the context of the Representation returned.]
A Resource can be thought of as an object that implements various interfaces. It is a concept, a notional software component that implements many interfaces. In REST those interfaces are identified by URIs.
Without constrained interfaces, a data-centric mode of interaction and identity, caches won’t work for example. This also means that Hypertext now becomes the engine of application state. Every component interface implements a state machine regardless of the underlining component technology, hence in REST URI become a way of making the application state explicit. Tim Ewald framed it nicely:
â€œThe essence of REST is to make the states of the protocol explicit and addressible by URIs. The current state of the protocol state machine is represented by the URI you just operated on and the state representation you retrieved. You change state by operating on the URI of the state you’re moving to, making that your new state. A state’s representation includes the links (arcs in the graph) to the other states that you can move to from the current state. This is exactly how browser based apps work, and there is no reason that your app’s protocol can’t work that way too. (The ATOM Publishing protocol is the canonical example, though its easy to think that its about entities, not a state machine.)â€
RPC (and therefore SOAP) rely on tool support to be vaguely usable. REST works because humans can do a wget and see what comes back. That reduces the coordination costs of building systems.
If you control all the components in the chain and you release them all at the same time and there is no latency issue to worry about, use a RPC style of interaction. Otherwise use REST. In today’s Web2.0 climate that means using a REST style, as a minimum, for externally exposed Resources via APIs.
An Architectural Style
REST is an Architectural Style in the true sense of Alexanderâ€™s patterns, compared to, the more prescriptive approach adopted by the Design Patterns movement, lead by the Gang of Four. SOAP is a XML language for specifying and constructing messages for a network protocol. The typical message exchange pattern is modelled after the RPC style. So just to confuse the matter SOAP can be compared more directly to HTTP; the latter being a Network API that attempts to conform to the REST style.
If REST is to be compared then it should be compared to RPC or SOA. Both are approaches to software architecture. SOAP is an implementation that can be used in either a Control-centric (RPC/SOA) style or a Document-centric (REST) style. It just happens than most uses of SOAP are RPCs.No comments
As I mentioned in a earlier post Roy Fielding has started a ASF Lab for Web Architecture that is intended to be a place to work on documentation regarding Web Architecture. This includes existing protocol improvements and Waka a new HTTP upgrade. Waka is still in the head of Roy Fielding and the changes have been eluded to over eight years in various ApacheCon presentations; in various Apache 2.0 design notes and emails focused mostly around the IO-layer and request-response processing chains in Apache 2.0; emails to rest-discuss and references to various draft RFC and previous HTTP next generation efforts – rHTTP, W3C’s HTTP-NG and Spero’s HTTP-ng.
From a podcast with Jon Udell, Roy describes Waka thus.
Waka is a binary token based replacement protocol for HTTP. The goal is to create a language independent mechanism for exchanging data oriented messages using the ReST architectural style – the principals and design.
An application protocol that is efficient as any custom protocol yet generally applicable like HTTP. The difference is that we get rid of HTTP syntax, make it possible to interleave meta-data and data in independent streams/frames. Doing this in a way that is efficient as possible without being entirely generic i.e. Waka is not attempting to replace TCP. This means Waka would be suitable to application integration inside the firewall and well as outside.
Why name it Waka? Waka is the Aotearoa (New Zealand) MÄori name for Canoe still used for ceremonial purposes. It is one of the few four-letter words suitable for a protocol name. And Roy is part MÄori.
From the last substantial presentation Roy gave about Waka the following can be gleaned.
Deployable within an HTTP connection via the HTTP/1.1 Upgrade header field with a defined mapping to HTTP/1.1 proxies.
A uniform syntax regardless of the message type and direction that also allows for padding for 32/64 bit alignment. There is a discussion in Chapter 6 of Roy’s dissertation covering uniform syntax and numerous discussions about the short-comings of layered encodings and MIME.
Messages are self-descriptive using explicit typing for message structure and fields. An indication of mandate and scope of the fields.
Association of meta-data to control, resource and representation. Allows for Premature termination of request or response.
To be more efficient the protocol will use tokens for all standard elements where a URI reference can be used in place of any token. Macros (client-defined syntax short-hand) can be established per connection. Meta-data delivery can be interleaved with data.
New Request Semantics
RENDER: display/print/speak this representation.
MONITOR: set up a subscription to be notified of resource state changes. Notification are sent to a resource specified as part of the request. Another name commonly used for these semantics is WATCH.
Authoring Method: DAV simplified and by that I would assume removal of the DAV property methods. Elimination of non-resource identifiers and reintroduction of PATCH.
Request control data: request identifier to support request pipelining removing the head-of-line bottleneck in HTTP. A Transaction identifier, a URI, meaning transactions can be treated as resources. And relative priority – relative to requests in a connections pipeline.
New Response Semantics
Self-descriptive binding to the request by echoing the request id, method and target URI. This basically enables an asynchronous transport.
Cache key explicitly described; caches no longer need to save request fields or guess about Vary information.
Unsolicited Responses for cache invalidation messages and multicast event notices.1 comment
The Web Architecture Lab is a work area for specifying and experimenting with the interrelated shared agreements (protocols) that make the World Wide Web a happy place. The goal is to produce a central storage for Web protocol evolution, including both existing Web protocols and new ones, that Apache developers can refer to, comment on, prototype alternatives, and provide examples and test cases. A secondary goal is to experiment with tools for integrating public commentary with the specification process.
Is WAKA still vaporspec? Totally. Does it still have to overcome the inertia of HTTP by proving at least an order of magnitude improvement (which HTTPNG and others failed to do)? Yes. Still, Roy has a pretty good track record, and Iâ€™d put my money on him (especially when backed
up by the ASF) over a bunch of vendors trying to sell â€œplatformâ€ any day.
A little more info in Roy’s Lab proposal.No comments