我有一个关于如何设计带有复合键的资源URI的问题。
我有一个称为Freight的资源，它具有4个键/ ID：合作伙伴ID，初始邮政编码，最终邮政编码和重量。
实际上，我的资源被设计为具有由数据库生成的增量ID，但是这种方法对API使用者而言并不是很好，例如，如果使用者/合作伙伴需要更新他们必须执行的货运信息：
获取运费？initialZipcode = {VALUE}＆finalZipcode = {VALUE}＆weight = {VALUE}
上面操作的响应将是货运ID，因此最终他们可以更新信息：
PUT运费/ {ID}
伙伴ID由身份验证机制隐含。
对我来说，似乎很奇怪，迫使合作伙伴在更新信息之前获取货运ID。
所以我的问题是：如何设计此URI？
PUT运费/初始邮递区号/ {VALUE} /最终邮递区号/ {VALUE} /重量/ {VALUE}
我是否需要考虑以上设计？
另一个问题：将partnerId嵌入身份验证机制中是一种好习惯吗？我知道优点（易于使用）和缺点（缓存，无法共享URI等），但是我不知道通常是好是坏。
谢谢！
没有错
PUT freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}
查询参数也是资源标识的一部分。
路径参数对于定义适合层次结构的资源很有用。在您的情况下，资源不太适合层次结构，因此请勿尝试将参数压缩到路径段中。
唯一的挑战是当客户端重新排列查询参数的顺序时该怎么做。您是否将其视为相同的资源，还是404？如果您不缓存GET响应，则可能无关紧要。
如果您为客户提供了一个URI模板供他们填写，那么他们以错误的顺序给您参数的可能性就很小。
如果您最初的建议是另一种选择，那就是您的GET返回带有货运ID的URI的重定向和位置标头。例如
GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE}
=>
302 See Other
Location: freight/1232321322
这样，您的客户就不必了解货运ID，只需抓住位置标头，然后按照重定向进行GET，或直接对Location标头中的URI进行PUT。这意味着，如果您决定以后不希望公开该ID，则可以在不破坏任何客户端的情况下更改URI。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句