Java Reference
In-Depth Information
er services could exchange application/vnd+xml;version=1.1 MIME types. You can
read more about these concepts in Chapter 9 .
All in all, because REST and HTTP have a layered approach to addressability, method
choice, and data format, you have a much more decoupled protocol that allows your service
to interact with a wide variety of clients in a consistent way.
Communicate Statelessly
The fourth RESTful principle I will discuss is the idea of statelessness. When I talk about
statelessness, though, I don't mean that your applications can't have state. In REST, stateless
means that there is no client session data stored on the server. The server only records and
manages the state of the resources it exposes. If there needs to be session-specific data, it
should be held and maintained by the client and transferred to the server with each request as
needed. A service layer that does not have to maintain client sessions is a lot easier to scale,
as it has to do a lot fewer expensive replications in a clustered environment. It's a lot easier
to scale up because all you have to do is add machines.
A world without server-maintained session data isn't so hard to imagine if you look back
12-15 years ago. Back then, many distributed applications had a fat GUI client written in
Visual Basic, Power Builder, or Visual C++ talking RPCs to a middle tier that sat in front of
a database. The server was stateless and just processed data. The fat client held all session
state. The problem with this architecture was an IT operations one. It was very hard for oper-
ations to upgrade, patch, and maintain client GUIs in large environments. Web applications
solved this problem because the applications could be delivered from a central server and
rendered by the browser. We started maintaining client sessions on the server because of the
limitations of the browser. Around 2008, in step with the growing popularity of Ajax, Flex,
and Java FX, the browsers became sophisticated enough to maintain their own session state
like their fat-client counterparts in the mid-'90s used to do. We can now go back to that state-
less scalable middle tier that we enjoyed in the past. It's funny how things go full circle
The final principle of REST is the idea of using Hypermedia As The Engine Of Application
State (HATEOAS). Hypermedia is a document-centric approach with added support for em-
bedding links to other services and information within that document format. I did indirectly
talk about HATEOAS in Addressability when I discussed the idea of using hyperlinks within
the data format received from a service.
Search WWH ::

Custom Search