Java 客户端和 Java EE 服务器通信答案

【问题标题】：Java client and Java EE server communicationJava 客户端和 Java EE 服务器通信
【发布时间】：2023-12-30 04:29:01
【问题描述】：

我有一个架构问题。我希望 Java 客户端与 Java EE 服务器（Glassfish）进行通信。我不想使用远程 EJB 调用并使用 GlassFish 应用程序客户端容器，我需要更轻量级的东西。所以我考虑通过 HTTP 调用。

从技术角度来看，RESTful 在我看来是最简单的方法。但我对建筑风格感到困惑。我的意思是，我不是在创建一个根据“资源”定义的系统，而是根据“方法”定义的系统。所以 JAX-WS 可能是合适的，但我更愿意不仅传输 XML，而且只是传输 HTTP 消息体中的原始数据。

我应该考虑 servlet 还是其他？客户端-服务器通信的最佳做法是什么？

【问题讨论】：

【解决方案1】：

http 消息正文中的原始数据

什么样的原始数据，例如以 base64 编码的字节？这听起来不像是 HTTP 的典型工作。在 EJB 和 Web 服务之间的某个地方，还有其他解决方案可能更适合并且可以更快。例如消息传递/序列化框架，如 Apache Thrift 或 Protocol Buffers。

无论如何，如果您采用 HTTP 方式：

有时可以将类似方法的端点建模为资源，但并不总是有效。如果没有资源，只需将其称为“Web API”，并仅保留对您有意义的 RESTful 概念和最佳实践。例如缓存、漂亮的 URL 以及利用 HTTP 状态代码和标头。

JAX-WS 不限于传输 XML。它虽然基于 WSDL，但您可能不需要。 REST API 更易于处理且更灵活。

JAX-RS 是构建任何类型的非 WSDL Web API 的不错选择。它提供了一个干净的 API 和许多有用的功能，即使您只将它用于简单的 GET/POST 操作。

【讨论】：

“如果没有资源，只需将其称为“Web API”，只保留对您有意义的 RESTful 概念和最佳实践”。 +1独自的。当存在其他更易于构建、理解和维护的解决方案时，人们往往过于关注 REST。
@Bogdan 是的，好像没有人敢再制作不是 REST 的东西了……或者他们无论如何都会称它为 RESTful，只是因为它有很酷的 URI。我真的希望超媒体 API/语义 Web 服务能够获得更多的关注，我觉得它们是唯一可以结束这种基于资源的疯狂的东西。