REST - Uniform Interface究竟是什么意思?

ric*_*ard 24 rest definition uniform-interface

维基百科有:

统一界面

统一接口约束是任何REST服务设计的基础.[14] 统一界面简化和分离了体系结构,使每个部分都能独立发展.该界面的四个指导原则是:

确定资源

在请求中标识单个资源,例如在基于Web的REST系统中使用URI.资源本身在概念上与返回给客户端的表示分开.例如,服务器可以将数据从其数据库发送为HTML,XML或JSON,其中没有一个是服务器的内部表示,并且它是相同的一个资源.

通过这些表示来操纵资源

当客户端持有资源的表示(包括附加的任何元数据)时,它具有足够的信息来修改或删除资源.

自我描述性的信息

每条消息都包含足够的信息来描述如何处理消息.例如,要调用的解析器可以由Internet媒体类型(以前称为MIME类型)指定.响应还明确指出了它们的可缓存性.

超媒体作为应用程序状态的引擎(AKA HATEOAS)

客户端仅通过服务器在超媒体内动态识别的动作(例如,通过超文本内的超链接)进行状态转换.除了应用程序的简单固定入口点之外,客户端不会假定任何特定操作可用于除先前从服务器接收的表示中描述的任何特定资源之外的任何特定操作.

我正在听这个主题的讲座,讲师说:

"当有人使用我们的API时,如果您能够获得客户对象并且您知道有订单对象,那么您应该能够获得具有与客户对象相同的模式的订单对象.这些URI是看起来像是彼此."

这让我觉得不对劲.这不是关于URI的外观或者是否存在一致性,因为它是使用URI的方式(识别资源,通过表示来操纵资源,自我描述性消息和hateoas).

我不认为这就是Uniform Interface的含义.究竟是什么意思?

inf*_*rno 35

使用接口将类与其依赖项的实现分离是一个非常古老的概念.我很惊讶你没有听说过......

通过REST,您可以使用相同的概念将客户端与REST服务的实现分离.为了定义这样的接口(客户端和服务之间的契约),您必须使用标准.这是因为如果您想要一个REST服务的Internet大小网络,您必须强制执行全局概念,例如标准,以使它们相互理解.

  • 资源标识 - 您使用URI(IRI)标准来标识资源.在这种情况下,资源是Web文档.

  • 通过这些表示来操纵资源 - 您使用HTTP标准来描述通信.因此,例如GET意味着您要检索有关URI标识资源的数据.您可以使用HTTP方法和URI描述操作.

  • 自描述性消息 - 您使用标准MIME类型和(标准)RDF词汇来使消息具有自我描述性.因此,客户端可以通过检查语义来查找数据,并且不必知道服务使用的特定于应用程序的数据结构.

  • 超媒体作为应用程序状态的引擎(AKA HATEOAS) - 您使用超链接和可能的URI模板将客户端与特定于应用程序的URI结构分离.您可以使用语义(例如IANA链接关系)来注释这些超链接,以便客户端了解它们的含义.

  • 因为它很简单.:-) (5认同)
  • 简单易懂的解释 (4认同)
  • 当然我听说过接口,我很清楚通过契约(接口)实现解耦的概念。我认为我缺少的是统一接口只是意味着这 4 个约束(资源识别、通过表示进行操作、自我描述消息和仇恨)。 (2认同)
  • "您可以使用HTTP方法和URI来描述操作." 仅当URI是基于HTML的.(mailto是非基于HTML的URI - 它们是基于mailto的.) (2认同)
  • 统一接口在哪里?您描述了其他原则,但询问者正在寻找统一接口... (2认同)

Céd*_*oys 10

任何 ReSTful 架构都应该遵守的统一接口约束实际上意味着,除了数据之外,服务器响应还应该宣布可用的操作和资源。

他的论文的第 5 章中,Roy Fielding(ReST 架构风格的创始人)指出,使用统一接口的目的是:

简化和改进全局架构和交互的可见性

换句话说,查询资源应该允许客户端在事先不知道的情况下请求其他操作和资源

JSON-API规范提供了一个很好的例子:

{
  "links": {
    "self": "http://example.com/articles",
    "next": "http://example.com/articles?page[offset]=2",
    "last": "http://example.com/articles?page[offset]=10"
  },
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON API paints my bikeshed!"
    },
    "relationships": {
      "author": {
        "links": {
          "self": "http://example.com/articles/1/relationships/author",
          "related": "http://example.com/articles/1/author"
        },
      },
      "comments": {
        "links": {
          "self": "http://example.com/articles/1/relationships/comments",
          "related": "http://example.com/articles/1/comments"
        }
      }
    },
    "links": {
      "self": "http://example.com/articles/1"
    }
  }]
}
Run Code Online (Sandbox Code Playgroud)

仅通过分析这个单一的响应,客户就知道:

  1. 什么是查询(articles在这个例子中)
  2. 如何结构化的文章对象(idtitleauthorcomments
  3. 如何检索相关对象(即author、 的列表comments
  4. 有更多的文章(10,基于当前响应长度和分页链接)

我希望这有帮助。
对于那些对该主题充满热情的人,我强烈建议您阅读Roy Thomas Fielding 的论文