0

I have developed a simple Spring MVC RESTful API and now I moved to the stage to create a simple GWT project to perform some requests to this api and obviously I choose that the communication will be done by exchanging JSON messages.

When receiving a response I will have to unmarshall it to a POJO.

I am aware that the general approach is to create the so called 'overlay types' but that looks to me as a mere duplicate of the java classes I wrote in api.

So the question is: why shouldn't I simply create a common api that simply contains the common classes to perform this marshalling/unmarshalling?

I can clearly see that the main benefit is that if any change is needed you won't have to change also the overlay types.

4

3 回答 3

1

假设您可以为您的 pojo 定义接口，您可以在客户端和服务器端共享这些接口（通用包）

在服务器端，您必须编写用于 RESTful api 的实现。

在客户端，这些接口的实现可以通过生成器自动完成。为此，您可以使用gwtquery 数据绑定或gwt autobeans。

要请求您的 RESTful api，您可以使用gwtquery ajax或 gwt requestbuilder

每个选项都有其优点，通常我使用 gwtquery 是因为它简单且因为它的数据绑定方法更轻量级，否则，使用 autobeans，您可以在客户端和服务器端使用 autobeans 工厂创建 POJOS。如果您已经开发了后端，那么这不是您的目标。

于 2013-08-29T10:33:32.457 回答
0

任何客户端都可以使用 REST 响应，而不仅仅是一个客户端。如果我正确理解您的问题，您想在 REST API 中构建编组和解组的逻辑。理想情况下，它违反了单一责任原则。如果服务发生更改，您可能需要更改映射逻辑，以便您触及 API 的两个不同方面，因为只有一个组件需要更改。

此外，理想情况下，REST API 应该设计为与客户端无关。将它们转换为 POJO 是您的特定要求，但另一个客户端可能希望将其作为简单的纯 JSON 使用。如果您提供覆盖类型，您的代码将非常松散耦合。

于 2013-08-29T09:18:11.263 回答
0

如果您的服务器端类（例如播放器）可以毫无问题地进行序列化/反序列化，那么您可以将其发送到客户端而无需任何覆盖类型/转换（在服务器上序列化为 JSON -> 传输 -> 在客户端从 JSON 反序列化） . 例如，在客户端，您可以使用 RestyGWT 来归档自动反序列化过程。只有在 Player 实例不能被序列化的情况下（例如它由 Hibernate 支持），才需要覆盖类型和转换过程。

于 2013-08-29T10:07:33.730 回答