REST - 如何使用复合键设计URI？

我有一个关于如何用复合键设计资源URI的问题。REST - 如何使用复合键设计URI？

我有一个称为货运的资源，它有4个键/ ID：合作伙伴ID，最初的邮政编码，最终的邮政编码和重量。

其实我的资源被设计成具有通过数据库生成一个增量的ID，但这种方法是不是那么好API的消费者，例如，如果一个消费者/合作伙伴需要更新他们所要做的货运信息：

？

GET货运initialZipcode = {VALUE} & finalZipcode = {VALUE} &重量= {VALUE}

的操作的响应以上将是货运ID，所以最后他们可以更新信息：

PUT货运/ {ID}

合作伙伴ID由认证机制隐含。

对我来说，在更新信息之前，似乎奇怪的是合作伙伴要获得运费ID。

所以我的问题是：我如何设计这个URI？

PUT货运/ initialZipcode/{价值}/finalZipCode/{价值} /重量/ {价值}

我是否考虑上面的设计？

另一个问题：是否将partnerId嵌入认证机制是一种很好的做法？我知道专家（对消费者而言容易）和缺点（缓存，不可能共享URI等），但我不知道一般是好还是坏的做法。

谢谢！

来源

2013-12-17 Krock

没有什么错

PUT freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}

查询参数的资源标识的一部分了。

路径参数对于定义适合层次结构的资源非常有用。在你的情况下，资源不适合层次结构，所以不要试图将参数压缩到路径段中。

唯一的挑战是当客户端重新排列查询参数的顺序时要做什么。你是否将它视为同一资源，还是404？如果你没有缓存GET响应，那么它可能没有关系。

如果您为您的客户提供了一个URI模板供他们填写，那么他们会以错误的顺序为您提供参数的可能性较小。

另一种选择，如果你与你原来的建议去是你的GET返回重定向和Location头到URI与货运ID。例如

GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE} 
=> 
302 See Other 
Location: freight/1232321322

通过这样做，你的客户不必知道货运ID任何东西，它可以只抢到位置标头，并按照重定向做一个GET，或者直接做PUT反对任何URI位于“位置”标题中。这意味着如果您决定不再公开此ID，则可以在不中断任何客户端的情况下更改URI。

来源

2013-12-17 14:40:32

嗨达雷尔，谢谢你的回答。对我来说，你的（第一）方法似乎很奇怪，因为我总是使用ID的概念，而不是像你展示的那样用作查询参数。对于我来说，查询参数决定了特定资源中的额外选项，例如：过滤器，搜索，排序，分页等。我在API中有其他一些情况来更新资源，并且在所有操作系统中， URI（路径参数），所以如果我有其他情况下的更新是带参数的，我觉得我伤害了统一接口的概念。我错了？ – Krock

@Krock RFC 3986指出查询参数是资源标识的一部分。它们不是一些额外的元数据。这是从以前版本的URI规范中作出的澄清。 http://tools.ietf.org/html/rfc3986#section-3.4客户端应该将整个URI视为不透明的标识符。 –

你说服了我:) 但在创建一个新的货运的情况下？我怎样才能返回回应？使用身份证件时，回复将作为创建运费的“地点”（例如：运费/ ID），但是如果我没有身份证件，回复是什么？货运地点？initialZipcode = {VALUE}＆finalZipcode = {VALUE}＆weight = {VALUE}？ – Krock

REST - 如何使用复合键设计URI？

回答

相关问题