java - REST是API，还是: REST vs Java Interface?

Question

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

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

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

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

我想表达的意思是 BookService是一个定义良好的接口(interface)，您(作为程序员)可以很容易地看到它期望的参数是一个标识符，它将返回一个 Book。目的。使用“just REST”，我们访问一些 URL，我们得到返回的任意数据。没有明确定义的接口(interface)，您不知道如何在不知道来自服务器的内部 URL 信息的情况下构建 URL，并且您必须“手动”解析 XML(希望使用 XSD)。

还有一点。我提到了书籍和作者。

当使用接口(interface)时，你可以有一个BookService返回 Book s 和一个 AuthorService返回 Author秒。 Book可以拥有属性(property)authorId你可以获得Author通过调用对象 Author getAuthor(int authorId) .

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

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

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

Answer 1

无论出于何种原因，都没有人按照 Roy Fielding 设想的方式使用 REST。所以这是不切实际的。对于懒人来说，不用考虑就够了。

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