繁体 English 中英

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

[英]Is REST an API, or: REST vs Java Interface?

原文 2012-09-17 21:38:04 6 7 java/ xml/ api/ rest/ standards

我与同事讨论过，他真的很喜欢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对象。 使用“只是REST”，我们访问一些URL，然后返回任意数据。 没有明确定义的界面，您不知道如何在不知道服务器的内部URL信息的情况下构建URL，并且您必须“手动”解析XML（希望使用XSD）。

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

当使用的接口，你可以有一个BookService返回Book S和一个AuthorService返回Author秒。 一Book可以有一个属性authorId ，你可以通过调用Author getAuthor(int authorId)来获取一个Author对象。

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

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

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

7 个解决方案

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使用ReST获得的优势很少

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

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

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