Ubiquitous language and maturity level in REST API?

Question

According to Richardson Maturity Model there are several levels of maturity in REST approach. http://martinfowler.com/articles/richardsonMaturityModel.html

Since DDD uses ubiquitous language, I am wondering what level of maturity is recommended, if a REST API is a presentation layer of my DDD project?

Using ubiquitous language could let to some interesting names inside a bounded context, but when exposing it to outside world, how could this be translated into an appropriate level of maturity?

Answer 1

REST maturity levels and DDD are orthogonal concerns.

Your Ubiquitous Language doesn't care whether it's reflected deep down in the payload of a SOAP message, in a resource URI, or in a domain-specific content type, as long as it remains pervasive and coherent throughout its Bounded Context.

If your Bounded Context includes both the client and server parts, HTTP will inevitably stand in your way, breaking the semantic continuity between the client and Application Service. If you adhere to the First Law of Distributed Objects, there's no way around it. When reading or programming client code, it will never be as fluid and easily discoverable as calling a method named after a domain concept on an object named after a domain concept. There will always be an impedence mismatch between the HTTP protocol commands and your domain verbs or commands.

If the BC ends at the Application Layer and/or acts as a Supplier or an Open Host Service to other systems, HATEOAS might provide a more clearly expressed and discoverable Published Language (in the form of a Domain Application Protocol) than the other levels, with less effort. But well-documented level 0, 1 or 2 implementations can remain perfectly valid depending on other contextual criteria.

Answer 2

If we consider that you're doing the server side and your "client" the client-side. A DDD would be something at least of HATEOAS approach but even probably more :

• adding new HTTP method relevant to the domain. Example DELETE could fit for a disabling and a reenabling could have a verb RESTAURE. (Yes this can be done with PUT but this is less domain driven).
• fully human readable URL which could conflict with the ubiquitous language defined with the client. For instance in the level 1 the URI people/1/address will give the address of the people with id one. But the ubiquitous language could expect to have something like people/address/id=1.
• Use another format that the one given in the link. Something that would follow the ubiquitous language instead of XML.

But if you're doing the client-side, your "REST" service can be at the level 0 (though it would not be a REST service according to the link) since it will be hidden from the client.

This is only a rough thought of the possibilities.