同一资源的不同REST风格的重新presentations [英] Different RESTful representations of the same resource

问题描述

我的应用具有 /富的资源。通常情况下，它是由一个HTTP响应负载这样psented重新$ P $：

My application has a resource at /foo. Normally, it is represented by an HTTP response payload like this:

{"a": "some text", "b": "some text", "c": "some text", "d": "some text"}

客户端并不总是需要这个对象的所有四个成员。什么是在 REST的语义办法让客户端告诉它在重新presentation所需要的服务器？例如如果它想：

The client doesn't always need all four members of this object. What is the RESTfully semantic way for the client to tell the server what it needs in the representation? e.g. if it wants:

{"a": "some text", "b": "some text", "d": "some text"}

应如何 GET 呢？一些可能性（我在寻找纠正，如果我误解了REST）：

How should it GET it? Some possibilities (I'm looking for correction if I misunderstand REST):

• GET /富？节= A，B，D 。
  
  
  
  • 查询字符串（称为的查询的字符串毕竟）似乎意味着寻找资源匹配这种情况，并告诉我他们，根据该资源对我没有重present这种定制。
  
  
  • GET /foo?sections=a,b,d.
    • The query string (called a query string after all) seems to mean "find resources matching this condition and tell me about them", not "represent this resource to me according to this customization".
    
    
    • 打破URI不透明，违反HATEOAS。
    
    
    • 似乎打破资源之间的区别（URI的唯一意义是确定一个资源），然后重新presentation。但是，这是值得商榷的，因为它是重新presenting 的presentable名单与 /部件一致/部件/＆LT; ID＆GT; 的资源，这是我从来没有遇到过问题。
    
    
    • Breaks URI opacity, violating HATEOAS.
    • Seems to break the distinction between resource (the sole meaning of a URI is to identify one resource) and representation. But that's debatable because it's consistent with /widgets representing a presentable list of /widget/<id> resources, which I've never had a problem with.
    
    
    • 乘以开销，这可以成为一个噩梦，如果 /富有数百组件和客户需要的100。
    
    
    • 如果我想支持 /富的HTML重新presentation，我不得不使用Ajax，这是有问题的，如果我只想要一个单一的HTML页面可以被抓取，通过简约的浏览器渲染等。
    
    
    • 要保持HATEOAS，它也需要链接到这些子资源等再presentations中存在，可能是在 /富： {一：{URL：/富/ A，内容：一些文本}，...}
    
    
    • Multiplies overhead, which can become a nightmare if /foo has hundreds of components and the client needs 100 of those.
    • If I want to support an HTML representation of /foo, I have to use Ajax, which is problematic if I just want a single HTML page that can be crawled, rendered by minimalist browsers, etc.
    • To maintain HATEOAS, it also requires links to those "sub-resources" to exist within other representations, probably in /foo: {"a": {"url": "/foo/a", "content": "some text"}, ...}
    
    
    • Unbookmarkable和不可缓存的。
    
    
    • HTTP没有定义的身体语义 GET 。这是合法的HTTP，但我怎么能保证一些用户的代理不从 GET 要求脱光身上？
    
    
    • 我的<一个href=\"https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?hl=en\">REST客户不会让我把身体上的 GET 的要求，所以我不能使用进行测试。
    
    
    • Unbookmarkable and uncacheable.
    • HTTP does not define body semantics for GET. It's legal HTTP but how can I guarantee some user's proxy doesn't strip the body from a GET request?
    • My REST client won't let me put a body on a GET request so I can't use that for testing.
    
    
    • 我宁愿避免自定义标题如果可能的话。
    
    
    • Unbookmarkable和不可缓存的。
    
    
    
    
    • 笨重;需要背的往复和一些奇怪的前瞻性code。
    
    
    • Unbookmarkable和不可缓存的，因为 /富/采购/ 1 就是这样只会使用一次，而且只保留，直到它被要求一个别名。
    
    
    • Clunky; requires back-and-forth and some weird-looking code.
    • Unbookmarkable and uncacheable since /foo/requests/1 is just an alias that would only be used once and only kept until it is requested.

    推荐答案

    我已经决定在以下方面：

    I've decided on the following:

    支持几个成员组合：我会拿出每一个组合的名称。例如如果一篇文章有​​作者，日期，和身体的成员， /条/一些-塞将返回所有的它和 /条/一些，蛞蝓/元将只返回作者和日期。

    Supporting few member combinations: I'll come up with a name for each combination. e.g. if an article has members for author, date, and body, /article/some-slug will return all of it and /article/some-slug/meta will just return the author and date.

    支持多种组合：我会用连字符分隔成员名称： /富/ A-B-C

    Supporting many combinations: I'll separate member names by hyphens: /foo/a-b-c.

    无论哪种方式，我会返回一个 404 如果组合是不支持的。

    Either way, I'll return a 404 if the combination is unsupported.

    从REST的定义：

    资源研究的是时间上变化隶属函数 M <子>研究 （ T ），这对于时间<我> T 映射到一组实体，或值，相当于中。在设定的值可能是资源再presentations和/或资源标识符。

    a resource R is a temporally varying membership function M_R(t), which for time t maps to a set of entities, or values, which are equivalent. The values in the set may be resource representations and/or resource identifiers.

    一个再presentation作为一个HTTP的身体和一个标识符是URL。

    A representation being an HTTP body and an identifier being a URL.

    这是至关重要的。身份标识只是与其他标识和再presentations关联的值。这是从识别→再presentation映射不同。服务器可以映射它想要的任何标识符任何重新presentation，只要两个由相同的资源相关联。

    This is crucial. An identifier is just a value associated with other identifiers and representations. That's distinct from the identifier→representation mapping. The server can map whatever identifier it wants to any representation, as long as both are associated by the same resource.

    这是给开发者拿出，通过像用户和岗位的事情类别的合理思维描述业务资源的定义。

    It's up to the developer to come up with resource definitions that reasonably describe the business by thinking of categories of things like "users" and "posts".

    如果我真的在乎完美HATEOAS，我可以把一个超链接某处 /富重新presentation到 /富/会员，及再presentation将只包含一个超链接的成员每个支持的组合。

    If I really care about perfect HATEOAS, I could put a hyperlink somewhere in the /foo representation to /foo/members, and that representation would just contain a hyperlink to every supported combination of members.

    从URL的定义：

    查询组件包含非分层数据，与路径部件数据一起，用于识别的URI的计划范围内的资源和命名授权文件（如有）。

    The query component contains non-hierarchical data that, along with data in the path component, serves to identify a resource within the scope of the URI's scheme and naming authority (if any).

    所以 /富？节= A，B，D 和 /富？部分= B 都是唯一的标识符。但他们可以相关在同一资源内而被映射以不同的再presentations。

    So /foo?sections=a,b,d and /foo?sections=b are distinct identifiers. But they can be associated within the same resource while being mapped to different representations.

    HTTP的 404 code 手段服务器找不到任何映射的URL，而不是该URL不与任何资源关联。

    HTTP's 404 code means that the server couldn't find anything to map the URL to, not that the URL is not associated with any resource.

    没有浏览器或缓存永远不会有斜杠或连字符的麻烦。

    No browser or cache will ever have trouble with slashes or hyphens.

    这篇关于同一资源的不同REST风格的重新presentations的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！