REST API 最佳实践 - 资源作为参数答案

【问题标题】：REST API best practice - resource as parameterREST API 最佳实践 - 资源作为参数
【发布时间】：2013-11-08 21:54:58
【问题描述】：

正如 OO 经常涉及参数为对象的方法一样，REST 似乎不可避免地导致需要将资源作为参数传递。如何做到最好？

一种方法似乎是资源的标量键是参数。所以我们可以通过fooid=21 来识别foo 类型的资源。可能是单个标量不足以识别资源，因此我们可能需要传递footype=a&fooelement=2。这看起来不太好，因为并不清楚这些标量参数是否实际连接并引用单个资源。

真的，如果参数是一个资源，它不应该被它的URI引用吗？所以我们可能想要传递更像/foo/21 或/foo/a/2 的东西。但是接下来有一个关于如何调用参数的问题。应该是foo=/foo/21？可能不是。明显的障碍是资源现在被过度指定了。我们知道 /foo/21 是 foo 资源的一个实例，没有被告知更多信息，我们不希望它可以写成 bar=/foo/21。

我们并不真正想要一个完全中性的参数名称，例如resource=/foo/21，因为如果多个参数是一种资源，它会提供信息不足且难以使用。

因此，参数名称可能应该描述参数与提供它的资源/方法之间的交互。但是找到合适的描述有多容易？

有人对这些问题有任何想法吗？

【问题讨论】：

'REST 不可避免地导致需要将资源作为参数传递。'我看不到那个。这样做的用例是什么？

标签： rest parameters url-parameters

【解决方案1】：

基本上，资源应该由其完整 URI 引用是正确的。这是最好的做法。时期。过度指定它是错误的，因为 URI 的语义对 REST 是透明的。客户端或服务器不应依赖 URI 来推断资源的类型。这就是媒体类型标头的用途。

参数如何命名，其实取决于与父资源的关系。例如，如果您有一个汽车资源和一个驱动程序资源，那么拥有car.current_driver = 'http://myapi/drivers/12' 并没有错，只要 Car 媒体类型的文档清楚地说明 current_driver 是什么。当尝试通过任何方法设置 Car 资源时，除了具有 Driver 媒体类型的资源之外，不应接受任何内容。

【讨论】：