REST -如何设计带有复合键的URI？
我有一个关于如何设计带有复合键的资源URI的问题。
我有一个名为货运的资源，它有4个键/ ID :合作伙伴ID、初始邮政编码、最终邮政编码和重量。
实际上，我的资源被设计为有一个由数据库生成的增量ID，但是这种方法对API使用者来说不是很好，例如，如果一个消费者/合作伙伴需要更新他们必须做的货运信息：
获取freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}
以上操作的响应将是货运ID，因此最后他们可以更新信息：
运费/{ID}
身份验证机制隐含了合作伙伴ID。
对我来说，似乎奇怪的是，迫使合作伙伴在更新信息之前获得货运ID。
所以我的问题是:我如何设计这个URI？
放置freight/initialZipcode/{VALUE}/finalZipCode/{VALUE}/weight/{VALUE}
我要考虑一下上面的设计吗？
另一个问题:在身份验证机制中嵌入partnerId是一个很好的实践吗？我知道优点(对消费者来说很容易)和缺点(缓存、不可能共享URI等)，但我不知道通常是好做法还是坏做法。
谢谢!
回答 1
Stack Overflow用户
发布于 2013-12-17 14:40:32
没有什么不对
PUT freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}查询参数也是资源标识的一部分。
路径参数对于定义适合层次结构的资源非常有用。在您的示例中，资源不能很好地适应层次结构，所以不要试图将参数压缩到路径段中。
唯一的挑战是当客户端重新安排查询参数的顺序时要做什么。你是把它当作相同的资源，还是404？如果您没有缓存GET响应，那么可能并不重要。
如果您为客户端提供了一个URI模板以供他们填写，那么他们给出错误顺序的参数的可能性就更小了。
另一种选择，如果您与您最初的建议是，您的GET返回一个重定向和一个位置标头到一个URI的运费ID。
GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}
=>
302 See Other
Location: freight/1232321322通过这样做，您的客户不必知道任何有关货运ID的信息，它只需获取位置头，然后按照重定向执行GET，或者直接对位置标头中的任何URI执行PUT操作。这意味着，如果您决定将来不愿意公开ID，则可以更改URI而不破坏任何客户端。
https://stackoverflow.com/questions/20635995
复制相似问题
腾讯云开发者
