构建这个REST URI的正确方法是什么？

Question

我想拥有一个Foo的REST资源，我希望能够执行POST来创建新的Foo。

Foos只能是两个子类型 - Fizz和Buzz（模型是后端的FooFizz和FooBuzz，两者都扩展Foo）。所有Foos都是Fizz或Buzz。大多数其他模型也遵循这种模式（通用与Fizz和Buzz的子类型）。在短期和中期内，Foos将不会增加新的类型。从长远来看，在添加新类型之前，该应用程序更有可能会过时，但存在这种可能性。

无论如何，这里有一些我为与Foos合作而想出的URI方案。

1. POST/foo的β型=香味

2. POST /富/香味

3. POST /香味/富

4. POST /富-香味

5. POST/foo/{foo-id}/fizz

我对此的看法：

（1）可能是不必要的客户端 - 服务器耦合，因为它依赖于正确形成的查询字符串。但它对我来说最有意义。 （2）和（3）是不受欢迎的，因为您希望能够使用URI go/foo/{foo-id}来对单个Foo执行操作。

（4）需要Fizzes和热闹非凡，成为URI树的完全独立的分支

（5）似乎是一个不错的方案，尽管它可能搞乱了URI树。

Answer 1

我会强烈地诱惑，只是有一个POST到/foo与正在由文档的内容决定要创建foo的类型（嘶嘶声或嗡嗡声）被张贴。它会响应一个合适的重定向到新创建的foo的URI（大概是/foo/{fooId}），通过它可以以正常方式操作事物。

Answer 2

无可否认，我不是一位REST专家，但这里是我的两分钱。

为什么你甚至会有一个帖子到foo/{foo-id}？在这种情况下，它更像是一个更新的PUT。您需要发布的唯一时间是如果该ID是自动创建，并且未知直到实际创建。所以，在这种情况下，我会倾向于1，因为您正在创建一个foo，剩下的只是创建foo所需的信息。在那之后，你甚至需要关心子类型（嘶嘶声或嗡嗡声）？我会假设foo/{foo-id}将有足够的信息来单独处理它并从中确定类型。

所以：

1. POST/foo的类型=嘶嘶声 **你可能甚至删除查询字符串，并把它作为你创作的数据，但最多也就是你
2. GET/foo/{foo-id} ...检索创建的foo
3. PUT/foo/{foo-id} ...更新创建的foo
4. DELETE/foo/{foo-id} ...删除创造foo

这就是我至少会做的事情。

Answer 3

<soapbox>If you are really doing a RESTful architecture, then you shouldn't need to ask this question</soapbox>。

RESTful体系结构在表示中包含指向应用程序流的链接。如果您正在创建作为父资源的子资源的新资源，则父资源的表示应该有一个嵌入式链接，用于告知您使用哪个URL和（可能）哪个谓词。喜欢的东西：

<link rel="add-child" method="POST" href="http://foo/1234">Add a new child</link> 

如果要创建一个全新的根资源，那么，你可能想POST为绝对URL，让无论是响应文件或Location头告诉你的应用程序在何处检索新表示。目标资源本质上是应用程序状态机的“入口点”。