REST是API，还是：REST与Java接口？

Question

我和同事讨论过，他真的很喜欢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是一个定义良好的接口，你（作为一个程序员）可以很容易地看到它所期望的参数是一个标识符，它将返回{{1对象。使用“只是REST”，我们访问一些URL，然后返回任意数据。没有明确定义的界面，您不知道如何在不知道服务器的内部URL信息的情况下构建URL，并且您必须“手动”解析XML（希望使用XSD）。

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

使用界面时，您可以Book返回BookService和Book返回AuthorService。 Author可以拥有属性Book，您可以通过调用authorId来获取Author对象。

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

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

那么为什么REST被认为是API？为什么我更喜欢REST而不是定义良好的（Java）接口？我如何混合两者？

Answer 1

在您选择的搜索引擎上查看Hypermedia APIs。

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

为何选择Hypermedia API？ REST是一个相当宽松和淡化的术语。通常执行不正确。最近有人试图澄清这种混乱，因此是“新”术语。正确完成后，您将获得REST（参见Hypermedia API）服务的强大功能，使用您熟悉的漂亮样式界面，使用Java / .NET中的强类型服务（ala SOAP，RPC）

Answer 2

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

显然，业界一直致力于为RPC发明不同的名称。

Answer 3

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

Answer 4

简而言之，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。

Answer 5

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

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

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

为简化起见，您可以将REST服务视为书架，从中可以获得一些书籍（资源），您可以在哪里发布新书或放置一本书...如果每个资源在问题方面都有意义域和如果资源表示包含相关资源的链接，我没有看到理解/消费它的问题。

Answer 6

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

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

只提供这两件事，我将能够为您的RESTful API构建客户端。从＃1开始，使用＃2的知识找到我的方法绕过系统的API“超链接”，我将能够找到我需要的资源。

了解系统的Book表示将允许我进行GET调用以检索并理解它，或者进行POST或PUT调用以创建一个。 HTTP支持那些开箱即用的动词，我只需要知道通过线路发送了什么（＃2告诉我）。

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

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

Answer 7

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

使用ReST获得的优势很少

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

关于服务定义，您可以为ReST服务生成wadl文件，以查看完整选项。大多数服务器自动生成这些。无论是SOAP还是ReST，都需要对服务进行详细记录。您可以查看LinkedIn ReST API。

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