在构建 RESTful 服务时，我总是遇到如何开发一个可以分发给系统用户的客户端库的问题。
举一个简单的例子，假设有一个实体调用者，并且您希望通过 RESTFul 服务支持基本的 CRUD 功能。
要救一个人，客户端需要调用POST方法并传递 适当的数据结构，例如 JSON。
要按生日查找人员，您的服务将回复包含人员对象列表的响应
- 要删除某人，您的服务将响应成功或 失败消息。
从上面的示例中，已经有两个可以与客户端共享的对象:人员对象和响应对象。我尝试了几种方法来实现这一目标:
将来自服务器调用的 Person 对象包含在客户端库中。这种方法的缺点是:
客户端代码与服务器代码紧密耦合。任何 服务器端的更改将需要客户端在期间进行更新 相同的版本。
Person 的对象可能包含用于 持久化或序列化。客户对此并不关心
库，但被迫包含它们。
包含 Map 的子类，它并不直接与 Person 的对象紧密相关，但包含一些用于设置所需字段的辅助类。
- 耦合较松散，但当服务器的数据结构发生更改时，可能会导致无提示错误。
- 使用描述性文件，如 Apache Thrift , WADL或Json Schema在编译时生成客户端对象。这解决了对象依赖关系的问题，但仍然产生了硬依赖关系。这几乎就像为 SOAP 创建 WSDL。然而，这种方法并未广泛使用，有时很难找到示例。
为您的应用程序发布客户端 jar 的最佳方式是什么，以便
- 客户易于使用
- 不会形成紧密耦合，并且不会对服务器端更改产生一定的容忍度
如果您的答案是更好的 API 文档，那么从 Java 注释和 POJO 生成这些文档的好工具是什么。
最佳答案
无论使用何种通信协议(protocol)，这都是一个常见问题。
在我们最近使用的一些 REST API(基于 JAX-RS)中，我们创建了 DTO 对象。这些只是愚蠢的 POJO(带有一些额外的注释，让 JAXB 自动为我们进行一些编码/解码)。我们将它们构建为子模块(在 Maven 中)，并将它们作为 JAR 提供，以便使用我们 API 的任何其他项目都可以根据需要使用 DTO。显然，如果您想提供自己的客户端库，则可以利用这些 DTO。将它们作为单独的 JAR 提供(任何应用程序都可以依赖)意味着客户端不会引入他们不需要的疯狂依赖项(您的整个服务器端代码)。
这使事情能够很好地解耦。
另一方面，您确实不需要提供客户端。毕竟是休息。前提是您的 REST API 构造良好并遵循 HATEOAS原则上，您的 API 应该易于抓取/浏览，即您不应该需要任何其他描述性方案。如果您需要 WADL 或其他类似的构造，您的 API 可能不是非常 RESTful。
关于java - 为 RESTful 服务创建客户端，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/15013223/