REST:针对不同资源表示级别的设计模式
我正在为许多资源设计REST，我需要维护至少2种相同格式的表示(例如JSON)，这些表示形式只在它们所公开的数据量上有所不同。
例如，我有书籍，出版商和作者，我是通过REST曝光的。所以我收集了3个资源：books、publishers和authors。当我请求一本书时，我希望它包含关于作者和出版商的最少信息--只有名字、it和指向它们的全部表示的超链接。
GET /books/12345
200 OK
{
id: "12345",
title: "My Book",
authors: [
{id:"111", name:"J. Smith", _href:"/authors/111"},
{id:"222", name:"J.R.R. Tolkien", _href:"/authors/222"}
],
publisher: {id:"333", name:"HarperCollins", _href:"/publishers/333"},
}当用户请求时，例如/publishers/333，它应该获得更多关于它的信息，而不仅仅是名称和id：
{
id: "333",
name: "HarperCollins",
address : { ... },
contact : { ... },
logo : { ... }
}在我的应用程序中，我有3个类Book、Publisher和Author，其中Book包含发布者和作者集合。我使用Jackson和Spring通过REST将所有实体公开为JSON。
@RequestMapping("/books/{id}")
@ResponseBody
public Book getBook(String id) {
return getBookById(id);
}
@RequestMapping("/authors/{id}")
@ResponseBody
public Book getAuthor(String id) {
return getAuthorById(id);
}现在的问题是：
- 在这种情况下，我如何告诉视图应该呈现哪个对象的字段？
- 我是否应该将我的实体分割成两个--一个是短的，另一个是完整的表示(例如
AuthorReference和Author，PublisherReference和Publisher)。 - 如果选择2，我应该更喜欢构图还是泛化？
- 在REST应用程序中，是否存在处理相同实体表示的不同脱节的最佳实践？
回答 2
Stack Overflow用户
发布于 2013-03-26 15:39:43
您是否考虑过使用更标准的超媒体格式，如硬件
这样做，很明显，您将有一个资源之间的区别，并链接到其他资源。例如，它可能以以下形式结束：
GET /books/123
200 OK
{
"id": "123"
"title": "My Book"
"_links": {
"author": [
{ "href": "/authors/111", "title": "J. Smith" },
{ "href": "/authors/321", "title": "Jules Verne" }
],
"publisher": { "href": "/publishers/123", "title": "Harper Collins" }
}
}在执行方面，我想说，你可以：
- 按照以下方式为每个资源表示创建自定义DTO类： 公共类BookDto { @JsonProperty(value="_links")公共LinkCollection getLinks() {}公共字符串getTitle() {}
- 使用相同的类，但是在Jackson序列化之前使用过滤器来修改对象，并使用@JsonProperty/@JsonIgnore的一些组合。
Stack Overflow用户
发布于 2013-03-26 20:29:53
1/根据Spring文档，要在HTTP上序列化您的对象，您必须使用T Book、Publisher或Author定义您自己的实现Book的类。http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/remoting.html#rest-message-conversion
[2]没有必要把你的对象分割成两半。从Author中选择哪些字段的逻辑包含在AuthorToHttp implement HttpMessageConverter<Author>中。当您希望通过HTTP发送更少的数据时，只需要开发一个要使用的AuthorReferenceToHttp implement HttpMessageConverter<Author>。
另一个解决方案可以是AuthorReference extend Author或Author extend AuthorReference，另一个是AuthorToHttp implement HttpMessageConverter<Author>和AuthorReferenceToHttp implement HttpMessageConverter<AuthorReference>，以序列化您的Author。
[3]继承/概括就足够了。不一定是对模式的需要。
复合是一个错误的选择，你不需要一个树结构。根据情况，您需要所有关于作者默认行为-的数据，或者关于作者的主要数据-“代理”行为-。代理将是一个更好的选择。
[4]不知道。
https://stackoverflow.com/questions/15640550
复制相似问题
腾讯云开发者
