2

Assume I have "shape" as a resource. I have 2 shapes one 'square' with ID 123, and 'circle' with 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"
}

Is it better to send different responses based on the type,
(or) Should i have 2 different types of resources altogether, having separate URI's such as v1/foo/shapes/squares/123, and v1/foo/shapes/circles/456, so that the client does not have to parse the response based on the "type" in the response.

4

4 回答 4

1

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

当要求一个特定的形状时，如果不需要这些属性来识别它，我不应该命名它的特定属性。

于 2013-10-05T04:01:37.297 回答
0

如果您想使用相同的 URL 结构但返回不同的内容，则应利用“统一接口”并根据返回的内容类型在响应中使用不同的 Content-Type 标头来指定您的内容是不同的。

或者，您可以使用配置文件来指定相同的差异。

于 2013-10-05T02:59:15.210 回答
0

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

于 2013-10-04T19:03:45.437 回答
0

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

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

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

设计“足够”首先解决问题，只要它不妨碍您将来扩展它。

于 2013-10-04T19:11:32.973 回答