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

Question

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

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

无论如何，我提出了一些与Foos合作的URI方案。

1. POST / foo？type = fizz

2. POST / foo / fizz

3. POST / fizz / foo

4. POST / foo-fizz

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

我对此的看法：

（1）可能是不必要的客户端 - 服务器耦合，因为它依赖于正确形成的查询字符串。但它对我来说最有意义。

（2）和（3）是不受欢迎的，因为你希望能够使用URI go / foo / {foo-id}来对单个Foo执行操作。

（4）要求Fizzes和Buzzes成为URI树的完全独立的分支

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

Answer 1

我很想成为/foo的POST，其中要创建的foo类型（fizz或buzz）由POST文档的内容决定 。它会通过合适的重定向响应新创建的foo（/foo/{fooId}的URI），通过它可以通过它来正常操作事物。

Answer 2

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

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

所以：

1. POST / foo？type = fizz **您甚至可以删除查询字符串并将其作为创建数据发送，但这取决于您
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标题告诉您的应用程序从哪里检索新的表示。目标资源本质上是应用程序状态机的“入口点”。