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

Question

我对如何使用复合键设计资源URI有疑问。

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

实际上我的资源被设计为具有由数据库生成的增量ID，但这种方法对于API消费者来说并不是那么好，例如，如果消费者/合作伙伴需要更新他们必须做的货运信息：

GET运费？initialZipcode = {VALUE}＆amp; finalZipcode = {VALUE}＆amp; weight = {VALUE}

上述操作的响应将是货运ID，因此最终他们可以更新信息：

PUT运费/ {ID}

合作伙伴ID由身份验证机制隐含。

对我来说，似乎很奇怪强迫合作伙伴在更新信息之前获取运费ID。

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

PUT运费/ initialZipcode / {VALUE} / finalZipCode / {VALUE} / weight / {VALUE}

我有没有考虑上面的设计？

另一个问题：将partnerId嵌入到身份验证机制中是一种很好的做法吗？我知道专业人士（容易消费者）和缺点（缓存，不可能共享URI等），但我不知道一般是一个好的或坏的做法。

谢谢！

Answer 1

没有错

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

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

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

唯一的挑战是当客户重新安排查询参数的顺序时该怎么做。你是否将它视为同一资源，或者你是404？如果您没有缓存GET响应，那么它可能无关紧要。

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

---

另一个选项是，如果您使用原始建议，那么您的GET会将重定向和Location标头返回给带有运费ID的URI。 e.g。

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

通过这样做，您的客户端不必了解货运ID，它可以只获取位置标题，并按照重定向进行GET，或直接对位置中的任何URI执行PUT头。这意味着如果您决定以后不喜欢公开ID，则可以在不破坏任何客户端的情况下更改URI。