Is it possible to apply the HATEOAS principle by SOA?

Question

The question is theoretical. I found that the difference between resource oriented architecture and service oriented architecture is similar to the difference between object oriented programming and procedural programming. By resource oriented architecture the service (namespace) publishes resources (objects) on which I can call methods (methods). By service oriented architecture the service (namespace) publishes operations (functions) which I can call.

By resource oriented architecture I can write a self-generating client because of HATEOAS principle. I only need to send back the data containing the urls of the linked resources. Is it possible to use similar approach by a service oriented architecture? If not then does it depend on the analogy with procedural programming, or is the reason something else?

Answer 1

It can be easily argued that a REST architecture is a SOA, it just has more constraints on it.

The HATEOAS aspect would have to be levered on top of the lower level SOA system, adding constraints to the payload. Don't forget that you don't heed HTTP to do HATEOAS. REST is not bound to HTTP, HTTP is just a protocol with REST inspirations baked in to it.

For example, in your SOA payload, you can have your own internal link refs. These will have URLs, but URLs don't have to look like http://example.com. They can be yourapp://your?custom!url:format. Everything after the first colon is interpreted by the scheme (yourapp in this case vs http).

These do not have to be direct references. In HTTP, they're not direct references, they rely on DNS look up host names, for example. You can implement you own look up mechanism using your own discovery protocol (LDAP, UDDI, /etc/hosts, whatever).

A SOAP header doesn't differ from an HTTP header. What differs are the semantics of how those headers are interpreted. You can always add a caching header to a SOAP payload if you have infrastructure to interpret it, for example.

So, it's certainly possible to add HATEOAS to a generic SOA. As you add more and more constraints from the REST architecture, you will slowly become more like REST. You may be completely unlike the Web, and HTTP, because you use different payloads, and different transports, and different protocols, but that's a detail. REST != HTTP.

Mind, I'm not saying it's easy. You'd have to do some of the lifting, the toolkits will fight you. But it's possible.