如何使用继承对 RESTful API 建模? [英] How to model a RESTful API with inheritance?
问题描述
我有一个需要通过 RESTful API 公开的对象层次结构，但我不确定我的 URL 应该如何构建以及它们应该返回什么.我找不到任何最佳做法.
I have an object hierarchy I need to expose through a RESTful API and I'm not sure how my URLs should be structured and what they should return. I could not find any best practices.
假设我有继承自 Animals 的 Dogs 和 Cats.我需要对狗和猫进行 CRUD 操作；我也希望能够对一般动物进行手术.
Let's say I have Dogs and Cats inheriting from Animals. I need CRUD operations on dogs and cats; I also want to be able to do operations on animals in general.
我的第一个想法是做这样的事情:
My first idea was to do something like this:
GET /animals # get all animals
POST /animals # create a dog or cat
GET /animals/123 # get animal 123
问题是/animals 集合现在不一致"，因为它可以返回和获取结构不完全相同的对象(狗和猫).集合返回具有不同属性的对象是否被视为RESTful"?
The thing is that the /animals collection is now "inconsistent", as it can return and take objects that do not have exactly the same structure (dogs and cats). Is it considered "RESTful" to have a collection returning objects that have differing attributes?
另一种解决方案是为每个具体类型创建一个 URL，如下所示:
Another solution would be to create an URL for each concrete type, like this:
GET /dogs # get all dogs
POST /dogs # create a dog
GET /dogs/123 # get dog 123
GET /cats # get all cats
POST /cats # create a cat
GET /cats/123 # get cat 123
但现在狗和猫之间的关系已经失去了.如果要检索所有动物，则必须同时查询狗和猫资源.URL 的数量也会随着每个新的动物子类型而增加.
But now the relationship between dogs and cats is lost. If one wishes to retrieve all animals, both the dog and cat resources must be queried. The number of URLs will also increase with each new animal subtype.
另一个建议是通过添加以下内容来增强第二个解决方案:
Another suggestion was to augment the second solution by adding this:
GET /animals # get common attributes of all animals
在这种情况下，返回的动物将只包含所有动物共有的属性，删除特定于狗和特定于猫的属性.这允许检索所有动物，尽管细节较少.每个返回的对象都可以包含指向详细的具体版本的链接.
In this case, the animals returned would only contain attributes common to all animals, dropping dog-specific and cat-specific attributes. This allows to retrieve all animals, although with fewer details. Each returned object could contain a link to the detailed, concrete version.
有什么意见或建议吗?
推荐答案
我建议:
- 每个资源只使用一个 URI
- 仅在属性级别区分动物
为同一个资源设置多个 URI 绝不是一个好主意，因为它可能会导致混乱和意想不到的副作用.鉴于此，您的单个 URI 应该基于像 /animals 这样的通用方案.
Setting up multiple URIs to the same resource is never a good idea because it can cause confusion and unexpected side effects. Given that, your single URI should be based on a generic scheme like /animals.
/animals URI 方法已经解决了在基础"级别处理整个狗和猫集合的下一个挑战.
The next challenge of dealing with the entire collection of dogs and cats at the "base" level is already solved by virtue of the /animals URI approach.
使用媒体类型中的查询参数和标识属性的组合可以轻松解决处理狗和猫等特殊类型的最后一个挑战.例如:
The final challenge of dealing with specialized types like dogs and cats can be easily solved using a combination of query parameters and identification attributes within your media type. For example:
GET/animals (Accept : application/vnd.vet-services.animals+json)
{
"animals":[
{
"link":"/animals/3424",
"type":"dog",
"name":"Rex"
},
{
"link":"/animals/7829",
"type":"cat",
"name":"Mittens"
}
]
}
GET/animals- 获取所有狗和猫，将返回 Rex 和 MittensGET/animals?type=dog- 获取所有狗，只会返回 RexGET/animals?type=cat- 获取所有猫，只获取手套GET /animals- gets all dogs and cats, would return both Rex and MittensGET /animals?type=dog- gets all dogs, would only return RexGET /animals?type=cat- gets all cats, would only Mittens
然后在创建或修改动物时，调用者有责任指定所涉及的动物类型:
Then when creating or modifying animals, it would be incumbent on the caller to specify the type of animal involved:
媒体类型:application/vnd.vet-services.animal+json
{
"type":"dog",
"name":"Fido"
}
上述负载可以通过 POST 或 PUT 请求发送.
The above payload could be sent with a POST or PUT request.
上述方案为您提供与通过 REST 的 OO 继承类似的基本特征，并且能够添加进一步的专业化(即更多动物类型)，而无需大手术或对您的 URI 方案进行任何更改.
The above scheme gets you the basic similar characteristics as OO inheritance through REST, and with the ability to add further specializations (i.e. more animal types) without major surgery or any changes to your URI scheme.
这篇关于如何使用继承对 RESTful API 建模?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
