4

我和一位同事讨论过，他真的很喜欢 REST，但我仍然必须相信它的好处。

我的主要问题是，从消费应用程序的角度来看，我并没有真正将 REST 视为 API 或一般接口。让我详细说明。我们有两个应用程序，其中一个使用 RESTful API 调用另一个。这是使用 JAX-RS 和 RESTeasy 实现的。但是，使用 RESTeasy，基于接口生成 REST 客户端也非常简单。

假设这是一个处理书籍和作者的系统。应用程序需要知道一本书，让我们假设它已经知道一些 ID。

  • 在 REST 中，它会调用例如http://server/book/21，返回任意有效负载并将其反序列化为Book对象。
  • 使用 RESTeasy 客户端，我们有一个BookService带有方法的接口Book getBook(int bookId)，我们只需调用getBook(21)并返回一个Book对象。

我要说明的一点是，这BookService是一个定义明确的接口，您（作为程序员）可以很容易地看到它期望的参数是一个标识符，它将返回一个Book对象。使用“just REST”，我们访问一些 URL，我们得到返回的任意数据。没有明确定义的接口，如果不知道来自服务器的内部 URL 信息，您不知道如何构建 URL，您必须“手动”解析 XML（希望使用 XSD）。

另一件事。我提到了书籍和作者。

使用接口时，您可以只有一个BookService返回Books 和一个AuthorService返回Authors。ABook可以有一个属性authorId，您可以Author通过调用Author getAuthor(int authorId).

使用 REST 时，您调用图书 URL 并返回有关作者的一些信息，包括作者的链接。然后，您可以点击链接以获取有关作者的更多信息。但是你怎么知道在哪里可以找到这个链接呢？并且出现了与之前相同的问题：如何构建链接，我如何知道如何解析返回数据？

当将两者混合时，可能会发生奇怪的事情。如果我只想Book通过 id 获取，我可能会调用BookService（它在内部以任何方式转换为 REST 调用）并获得一个不错的Book对象。但是，如果我想获取作者信息，我有 this String authorLink，我必须按照它来获取我的Author对象。但相反，当我的起点是 anAuthor并使用 检索它时AuthorService，我会在指向书籍对象的字符串 (URL) 集合中获得作者所写书籍的链接。

那么为什么 REST 被认为是一种 API？为什么我应该更喜欢 REST 而不是定义明确的 (Java) 接口？以及如何将两者混合？

4

7 回答 7

3

无论出于何种原因，没有人以 Roy Fielding 设想的方式使用 REST。所以这是不切实际的。对于懒惰的人来说，这足以不必考虑它。

显然，业界痴迷于为 RPC 发明不同的名称。

于 2012-09-17T21:58:33.407 回答
2

在您选择的搜索引擎上查看超媒体 API。

有一些很好的文献可以解释你如何“知道”要调用什么，有什么请求。特别是HATEOS。

为什么选择超媒体 API？REST 是一个相当松散和淡化的术语。经常执行不正确。最近出现了试图消除这种混淆的热潮，因此出现了“新”术语。正确完成后，您将获得 REST（请参阅超媒体 API）服务的强大功能，该服务具有您熟悉的在 Java/.NET 中使用强类型服务（ala SOAP、RPC）之类的漂亮样式界面

于 2012-09-17T21:41:23.507 回答
1

REST 不是 API，而更像是一种架构。REST 用于通过现有的 HTTP 协议在 2 个不同的系统之间进行通信。REST 对很多事情都很有意义，也许在你的情况下你不需要使用它。

于 2012-09-17T21:43:13.717 回答
0

如果您考虑有关构建分布式应用程序/系统的工具的 REST（架构而非设计或编码风格），而不是使用众所周知且经过验证的概念（在万维网上）来管理应用程序状态的主要意图，那么使用它是有意义的在某些情况下。

当您想将一些处理/计算从一个应用程序移动到某个远程主机（比如说检索书籍列表）时，您可以通过将方法调用（GetBooks）序列化为 SOAP 消息来做到这一点，然后将该消息添加到 http 请求等中。 . 或者您可以调用 GET /books.. 在某些情况下，使用 ti 以第二种方式便宜得多。如果我提到了一些其他的东西，比如资源缓存，它是基础设施的一部分，而不是当你想要相同资源的不同表示时，它是显式实现的或灵活性，那么它甚至会更有意义。

如果某些服务使用 REST 风格并且编写得很仔细（就像任何 API 一样），那么它很容易理解和使用。这些类型的服务也可以很容易地从没有像 JAX-WS 或 WCF 这样的框架的不同类型的客户端（javascript、php、..）中使用。

为简化起见，您可以将 REST 服务视为书架，您可以从中获取一些书籍（资源），您可以在其中发布新书或放置您获得的书籍.. 如果每个资源在问题域方面有意义，并且如果资源表示包含指向相关资源的链接，而不是我看不到理解/使用它的问题。

于 2012-09-17T22:35:20.987 回答
0

您误解了 REST 的关键部分。在一个设计良好的 RESTful 系统中，有两件事必须有很好的文档记录：

  1. 用于开始与系统交互的入口点（或“酷”URI）
  2. 在请求中发送并在响应中返回的有效负载数据的模式（在 HTTP 术语中，这些是媒体类型）

只要给我这两件事，我就能为你的 RESTful API 构建一个客户端。从#1 开始并使用#2 的知识来找到解决系统API“超链接”的方法，我将能够找到我需要的资源。

了解您的系统Book表示将允许我进行 GET 调用来检索并理解它，或者进行 POST 或 PUT 调用来创建一个。HTTP 开箱即用地支持这些动词，我只需要知道通过网络发送的内容（#2 告诉我）。

如果我不喜欢 XML，我可以尝试询问服务器是否可以使用 JSON，而 HTTP 支持开箱即用的那种内容协商。

REST 不是独角兽制造的魔法粉，它不会仅仅因为被使用就能解决你的问题。然而，它是一种常识性架构，它试图利用现有的经过充分验证、易于理解、可扩展和灵活的技术和方法。

于 2012-09-18T01:54:07.230 回答
0

ReST是一种架构风格，而不是 API。

使用 ReST 获得的一些优势

  1. 多响应类型能力（例如：JSON、XML） ReST 不像 SOAP 那样绑定到 XML
  2. 使用 JSON 使您的有效负载轻量级并且您的服务更快
  3. 更容易开发和测试
  4. ReST 使用纯 HTTP，因此没有与代理相关的问题

关于服务定义，您可以wadl为您的 ReST 服务生成一个文件以查看完整选项。大多数服务器会自动生成这些。无论是 SOAP 还是 ReST，服务都需要有很好的文档记录。您可以查看LinkedIn ReST API。

我看到 SOAP 的唯一优势是 SOAP 可以提供的安全特性。但并非所有应用程序都需要这种级别的安全性。

于 2012-09-18T11:12:47.400 回答
0

简而言之，REST API 对于其他编程语言是灵活的。

我不熟悉 RESTEasy，但熟悉 RESTful 服务。REST 没有标准。大多数 REST 服务都会发布如何与其 REST API 交互。可用的 URL（资源）、要发送的内容类型以及将返回的类型。好的也会公布会返回什么http状态码以及如何处理错误。在您的情况下，我想知道 REST Easy 客户端在做什么。它只是将 API 调用转换为 HTTP 请求并为开发人员处理所有事情吗？

我们记录我们的 REST API 调用并提供一个包含所有模型的 jar 文件。这些模型使用 JAXB 注释，因此开发人员无需了解有关从服务返回的 XML 或 JSON 的所有信息。也就是说，如果他们使用 Java 和我们的模型。发布和记录 API 的好处是其他语言的开发人员可以使用该服务，前提是他们可以发出 HTTP 请求。这允许开发人员以几乎任何编程语言开发客户端应用程序。（最近似乎有更多的 C# 实现）。

除了提供模型的 jar 文件外，我们还在我们的文档中为非 Java 开发人员提供了 XSD。

于 2012-09-17T22:08:59.847 回答