【发布时间】：2014-10-22 18:38:29
【问题描述】：
我正在尝试设计一个充分利用超媒体的 RESTful 服务。
最好，用户代理应该只知道根 URI，以便能够探索服务的所有功能 - 也就是说，我希望它位于 maturity model 的第 3 级。
现在，用户代理应该能够创建一些资源并在以后编辑它们。在创建/编辑时，用户代理需要访问其他一些资源/枚举。
foo 资源：
{
"category" : "category chosen from an enumeration of possible categories",
"color" : "color chosen from an enumeration of possible colors",
"aRelatedResource" : "resource identifier from chosen from a collection"
}
鉴于前面提到的要求，我想出了以下模式：
拥有 fooRoot 资源：
{
// no properties, only links
"_links" : {
"foos" : { "href" : "URI-to-foos" },
"fooCreator" : { "href" : "URI-to-plain-fooWriter" }
}
}
在 foo 资源中包含一个 link 到 fooWriter：
foo 资源：
{
"category" : "category chosen from an enumeration of possible categories",
"color" : "color chosen from an enumeration of possible colors",
"aRelatedResource" : "resource identifier from chosen from a collection",
"_links" : {
"self" : {...},
"fooEditor" : { "href" : "URI-to-fooWriter-initialized-for-current-foo" }
}
}
fooWriter 如下所示：
{
"fooPayload" : {
"category" : "NULL or pre-initialized",
"color" : "NULL or pre-initialized",
"aRelatedResource" : "NULL or pre-initialized"
},
"_links" : {
"fooPayloadDestination" : { "href" : "URI-to-foos-or-foo" },
"categoryEnum" : { "href" : "URI-to-categories" },
"colorEnum" : { "href" : "URI-to-colors" },
"availableResourcesToRelateWith" : { "href" : "some-other-URI" },
....
.... and even something useful for pre-validation etc.
"validator" : { href : "URI-to-some-resource-or-service" }
}
}
总而言之，任何可以创建和编辑的资源都可能具有关联的writer资源。
通过 GET-ting writer，用户代理可以非常方便地创建/编辑资源。
写入器中嵌入的 payload 被 POST 到它的 destination 并且瞧 :)
此外，还应该有一个 root 容器，其中包含指向资源及其新资源编写器的链接（请参阅上面示例中的 fooRoot）。
问题是……
...上面描述的模式有一个众所周知的名字吗？
...有没有更好的方法来解决 create / edit 问题，其中 create / edit时间和第三级成熟度仍然“成立”？
一些参考资料：
【问题讨论】：
-
为什么
foo资源中没有包含自链接，为什么不通过对自链接执行 PUT 来简单地更新资源？这似乎比你的方法少了很多工作。 -
@JonathanW，谢谢 :) 但是，“colorEnum”、“categoryEnum”等的链接呢？我也应该将它们添加到 foo 资源中吗？如何创建一个新的 foo，而不是编辑现有的？在这种情况下，这些链接会嵌入到哪里？
-
因此，您可能没有得到回复的部分原因是您最初的问题是非常开放的。为了直接回答你的问题，这个模式没有我知道的名字。至于模式是否“好的”，我不确定你的意思。模式只是用于设计某些东西的模板，根据定义，它通常是适用的。那么...这真的是您想要回答的问题，还是 this 模式是否是解决您的问题的最佳方式的问题？
-
@JonathanW，再次感谢 :) 我已经更新了帖子末尾的问题。我想最重要的是我需要一些关于所描述解决方案的社区反馈。它看起来可重用 & 普遍适用，它适合一系列常见问题，所以我们可以称之为模式 .但它没有名字:)
-
如果枚举是一组静态的可能性，我只会记录可能的值并在服务器上验证。我不会尝试将它作为链接烘焙到交换中......但如果有很多信息并且枚举本身指向不同的资源，你可以像我在示例中对欧洲防风草所做的那样做类似的事情.
标签： rest design-patterns web restful-architecture hypermedia