Proper way of implementing HATEOAS with ServiceStack

Question

I know how mythz generally feels about HATEOAS, but let's say that I have to follow the HATEOAS principles in my REST services and add links ("self", "parent", and other possible relations) to my DTOs.

Links like "self" and "parent" contains paths to the resources and those paths are of course related to my routes.

I'm using the following project/deployment structure for my ServiceStack REST service. If that matters, I'm using ServiceStack 3.9.71.

Service Gateway Assembly:

• defines my DTOs. Each DTO has a factory creating that DTO from the corresponding domain object
• defines operations and their routes

Service Implementation Assembly:

• uses ServiceGateway to get DTO definitions and access their factories
• does whatever domain logic requires and create the corresponding DTOs through the afore mentioned factories

Service Interface Assembly:

• define my REST services and
• calls ServiceImplementation from ServiceStack's HttpHandler, according to REST verbs (GET, POST, ...)

WHERE would be the proper place to add link information to my DTOs?

Option1:

In my Service Gateway, when I build the DTOs themselves. It seems logical: I know what I need to know about my domain objects and I can easily build the links. Except that my DTOs are now all including an additional member (Links) and building those links forces me to explicitly provide paths/routes (i.e. hard code them). Seems to lead to a maintenance nightmare.

Option2:

In my Service Interface assembly, where I have the request context and I know my routes. I can encapsulate whatever my Service Implementation returns in a meta-object containing the response and a link collection. However, to build that link collection, I sometimes need information available at the domain (i.e. Service Implementation) level. The big "con" side for me is that it creates a new additional and artificial level in all my responses. Could be seen as a way to standardize response formats but I don't like it.

Option3:

My hope is that I can write a wrapper generically "injecting" a "Links" member to all the DTOs I return by hooking somewhere into ServiceStack in my Service Interface assembly. I haven't investigated much in that direction because I feel I could be wrong on the whole approach here.

Any advise / suggestion welcome. Thanks to all.

Answer 1

I'm not sure If I'm suggesting you option1 or option3, but this Is what I came out after trying to do the same thing.

I started from this answer.

Now you can access route metadata directly from filters.

So my current approach is:

=> Services create the dto responses and the next collection of hypermedia links that will be attached to the response. In this level you know the "operations" by type but not "how" you will build the routes. I think it is coherent that domain level deals with workflows of operations.

=> Within a response filter I get the available routes from Metadata, and build the routes from dto properties by convention. Finally routes are added to http header.

Caveats: I'm mapping 1 dto - 1 route. This approach could be more difficult in other cases.