使用ServiceStack实现HATEOAS的正确方法

Question

我知道mythz对HATEOAS的看法一般 ，但是我要说我必须遵循我的REST服务中的HATEOAS原则，并在我的DTO中添加链接（“self”，“parent”和其他可能的关系）。

像“self”和“parent”这样的链接包含资源的路径，这些路径当然与我的路由相关。

我正在为ServiceStack REST服务使用以下项目/部署结构。 如果这很重要，我正在使用ServiceStack 3.9.71 。

服务网关组装：

• 定义我的DTO。 每个DTO都有一个工厂从相应的域对象创建该DTO
• 定义操作及其路线

服务实施大会：

• 使用ServiceGateway获取DTO定义并访问其工厂
• 做任何领域逻辑需要并通过上述工厂创建相应的DTO

服务接口组件：

• 定义我的REST服务和
• 根据REST动词（GET，POST，...）从ServiceStack的HttpHandler调用ServiceImplementation

在哪里可以将链接信息添加到我的DTO中？

选项1：

在我的服务网关中 ，当我自己构建DTO时。 这似乎是合乎逻辑的：我知道我需要知道的关于我的域对象的内容，我可以轻松地构建链接。 除了我的DTO现在都包括一个额外的成员（链接）并建立这些链接迫使我明确提供路径/路由（即硬编码）。 似乎导致维护噩梦。

选项2：

在我的服务接口程序集中，我有请求上下文，我知道我的路由。 我可以封装我的服务实现在包含响应和链接集合的元对象中返回的任何内容。 但是，为了构建该链接集合，我有时需要在域（即服务实现）级别提供的信息。 对我来说，最大的“骗局”是它在我的所有回复中创造了一个新的额外和人为的水平。 可以看作是一种标准化响应格式的方法，但我不喜欢它。

2选项：

我希望我可以通过在我的服务接口程序集中将ServiceStack连接到某个地方，将一个“链接”成员写入一个包装器，一般地“注入”一个“链接”成员到我返回的所有DTO。 我没有在那个方向上调查太多，因为我觉得我在这里的整个方法可能是错的。

任何建议/建议欢迎。 谢谢大家。

Answer 1

我不确定如果我建议你选择1或选项3，但这是我在尝试做同样的事情后出来的。

我从这个答案开始。

现在， 您可以直接从过滤器访问路径元数据 。

所以我目前的做法是：

=>服务创建dto响应以及将附加到响应的下一个超媒体链接集合。 在这个级别，您可以按类型了解“操作”，但不知道您将如何构建路径。 我认为域级处理操作工作流程是一致的。

=>在响应过滤器中，我从Metadata获取可用路由，并按照惯例从dto属性构建路由。 最后路由被添加到http标头。

警告：我正在绘制1 dto - 1路线。 在其他情况下，这种方法可能更难。