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

Question

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

我有一个名为货运的资源,有4个密钥/ ID:合作伙伴ID,初始邮政编码,最终邮政编码和重量.

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

GET运费？initialZipcode = {VALUE}&finalZipcode = {VALUE}&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.例如

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

通过执行此操作,您的客户端不必知道有关货运ID的任何信息,它可以只获取位置标头,并按照重定向进行GET,或者直接针对Location头中的任何URI执行PUT.这意味着如果您决定以后不喜欢公开ID,则可以在不破坏任何客户端的情况下更改URI.