Question

假设我有“形状”作为资源。我有2个形状，一个'正方形'，ID为123，而'圆圈'，ID为456.

So when i do a GET on the 123 I will get a response : v1/foo/shapes/123
{
  "id": "123",
  "type": "square",
  "side-lenght" : "6",
  "area" : "36"
}
When i do a GET on 456 i will get a response : v1/foo/shapes/456
{
  "id": "456",
  "type": "circle",
  "radius" : "7",
  "area" : "154"
}

根据类型发送不同的回复是否更好，
（要么）我应该有两种不同类型的资源，具有单独的URI，例如 v1/foo/shapes/squares/123和v1/foo/shapes/circles/456，以便客户端不必根据响应中的“类型”解析响应。

Answer 1

如果形状类型必然是其唯一标识符的一部分，那么它应该是URL的一部分。但是，如果id足以识别任何形状，无论其形状如何，那么我会说不将形状类型放在网址中。

当要求特定形状时，如果不需要识别它们，我就不必为它的特定属性命名。

Answer 2

这方面没有正式的标准，任何一种方法都是可以接受的。 REST没有规定URL结构的粒度，而是关心动词。

Answer 3

客户端需要知道如何以某种方式解析返回的数据。这只是在执行流程（或抽象级别）中客户端代码开始意识到形状的问题。

您的问题的答案将取决于是否有用例将“形状”空间划分为方形，圆形等子空间。

如果没有这种需要，你应该只使用'/ shapes / id'。如果您以后需要，可以随时添加。如果您将返回的数据保留在其中，则API仍将正常工作。

设计'足够'以便首先解决问题，只要它不会阻止您将来扩展它。

Answer 4

如果您想使用相同的网址结构但返回不同的内容，那么应该利用“统一界面”并根据返回的内容类型，在响应中使用不同的Content-Type标头指定您的内容不同

或者，您可以使用profile来指定相同的差异。

最好在REST中拥有单独的资源或不同的响应

4 个答案: