Fatal编程技术网
  • architecture/
  • Architecture 关于休息，我不了解什么？

Architecture 关于休息，我不了解什么？

architecture rest

Architecture 关于休息，我不了解什么？,architecture,rest,Architecture,Rest,我正在构建一个框架，希望使用它构建的开发人员能够允许它的一部分与其他站点共享数据，并允许其他站点添加/编辑/删除数据 例如，如果有人制作了一个包含书评、作者、引用、代码示例、评论等内容的网站，开发人员可以将其他网站的“书评”设置为只读，将其他网站的“评论”设置为可读，并将某些网站/用户的“评论”设置为可写。其思想是使用该框架构建可以轻松与其他应用程序互连的应用程序 我设想通过POST和GET实现与站点的所有交互，其外观如下： /books.php？category=ruby（返回关于ruby的

我正在构建一个框架，希望使用它构建的开发人员能够允许它的一部分与其他站点共享数据，并允许其他站点添加/编辑/删除数据

例如，如果有人制作了一个包含书评、作者、引用、代码示例、评论等内容的网站，开发人员可以将其他网站的“书评”设置为只读，将其他网站的“评论”设置为可读，并将某些网站/用户的“评论”设置为可写。其思想是使用该框架构建可以轻松与其他应用程序互连的应用程序

我设想通过POST和GET实现与站点的所有交互，其外观如下：

  • /books.php？category=ruby（返回关于ruby的书籍的XML集合）
  • /books.php？id=23（返回特定书籍的XML）
  • /books.php？action=add&title=AdvancedRuby&description=..&securityId=923847203487
  • /books.php？action=delete&id=342&securityId=923847203487
其他应用程序也可以通过以下方式“发现并消费”某个站点提供的内容：

  • /discover.php（返回所有可用公共类和操作的XML）
实际上，这就是我所需要的，使框架成为开发人员快速创建松散连接站点的一种方式

我想知道的是，在我开始实施之前，我是否还不了解REST中哪些重要/有趣的部分应该构建到框架中，例如：

  • REST需要GET、POST、PUT和DELETE。为什么我需要“放”和“删除”？如果我不使用这些标准，我是否会阻止自己利用这些标准
  • 我的“discover.php”文件的功能类似于web服务中的WSDL文件。我对REST的描述感到惊讶，似乎没有标准化的方法来发现RESTful服务提供的服务，或者说有没有
  • 如果客户端网站尝试（例如）向服务器网站添加一本书，但没有收到任何“成功”响应，则只需重试，直到收到响应为止。服务器网站不会两次添加同一本书。这就是我对REST中数据完整性的理解，还有比这更重要的吗
  • 最终，我希望有多个具有相同富类的站点，例如“BookReview”，以便客户端站点能够执行如下代码：

    $bookReview=新的bookReview（“”）； $book->informAuthor（“关于您的书评的评论已发布在我们的网站上…”）

服务器站点将向该评论的作者发送一封电子邮件。
这种类型的类型交互是RESTful哲学的一个组成部分，还是REST仅仅是通过XML、JSON交换数据？

如果我不使用这些标准，我是否会阻止自己利用这些标准？

您自己正在从HTTP标准中锁定。当然，您可以使用GET参数执行相同的操作。那不是休息，而是类似RPC的东西

我可以推荐莱纳德·理查森和山姆·鲁比的那本书吗？这本书读起来很有趣，并且展示了不同方法之间的差异

更详细地回答你的问题：由你决定你走哪条路。理论上，您可以使用RESTful和类似RPC的方法完成所有相同的工作。使用RESTful，您可以使用底层HTTP协议作为协议。使用RPC，您可以将HTTP用作传输手段，并将工单隐藏在传输数据中的某个位置。这会导致（不需要的）开销

请看两个示例：

  • /books.php？action=add&title=AdvancedRuby&description=..&securityId=923847203487
  • /books.php？action=delete&id=342&securityId=923847203487
    • 有POST和PUT或DELETE，为什么有action=add和action=DELETE
    • 还有HTTP认证。为什么要发明一个可能不太安全的securityId
    • 顺便说一句：您不应该允许通过GET更改数据。这只是不应该做的事情（不过，这是另一个话题；）
我建议你阅读罗伊·菲尔丁的这篇文章

亮点：

  • REST API应该将其几乎所有的描述性工作用于定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体类型定义扩展关系名称和/或支持超文本的标记。描述在感兴趣的URI上使用什么方法的任何工作都应该完全在媒体类型的处理规则范围内定义（在大多数情况下，已经由现有媒体类型定义）。[此处的失败意味着带外信息驱动的是交互，而不是超文本。]

  • RESTAPI不能定义固定的资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须有控制自己名称空间的自由。相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指导客户机如何构造适当的URI，例如在HTML表单和URI模板中完成。[此处的失败意味着客户端由于带外信息（例如特定于域的标准，它是面向数据的，相当于RPC的功能耦合）而采用资源结构]

您当然可以成功地使用您描述的类似RPC的方法，而且它比“适当的RESTAPI”更容易掌握。REST最容易被误解的方面是，一旦定义，它应该自动工作，您不应该使用此方法定义go to此URI以获得答案，这应该由您提供的媒体类型以及让客户知道在哪里找到相关res的方法暗示 
GET /search?type=books&category=ruby

GET /books/23 (or /books/23.xml)

POST /books
title=AdvancedRuby&description=A+great+book...

DELETE /books/342

POST /books/342
status=Deleted