Teaching old services new tricks: adding HATEOAS support as an afterthought

Abstract

Hypermedia as the Engine of Application State, or HATEOAS, is one of the constraints of the REST architectural style. It requires service responses to link to the next valid application states. This frees clients from having to know about all the service's URLs and the details of its domain application protocol. Few services support HATEOAS, though. In most cases, client programmers need to duplicate business logic and URL schemas already present in the service. These dependencies result in clients that are more likely to break when changes occur. But existing services cannot be easily updated to support HATEOAS: Clients could cease working correctly when a service is changed. Also, client developers might not have access to the service's source code, be it for technical or political reasons. We discuss which information is needed to create a HATEOAS-compliant wrapper service for an existing service. We include a notation for modeling possible application states and transitions based on UML State Charts. We demonstrate the feasibility and advantages of our approach by comparing the clients for an existing service and its wrapped counterpart. Our approach enables client developers to wrap third-party services behind an HATEOAS-compliant layer. This moves the tight coupling away from potentially many clients to a single wrapper service that may easily be regenerated when the original service changes.