简体繁体 English

GWT：使用相同的api在客户端和服务器端进行JSON解析

[英]GWT : JSON Parsing in client side and server side with same api

原文 2012-07-13 06:05:23 3 2 json/ gwt/ smartgwt

We use org.json api to parse json on server side and GWT JsonParser to parse JSON on client side. 我们使用org.json api在服务器端解析json，并使用GWT JsonParser在客户端解析JSON。 Is there a api that we can use that can be used on both the client side and server side? 有没有可以在客户端和服务器端都可以使用的api？

2 个解决方案

You are looking for GWT AutoBean: http://code.google.com/p/google-web-toolkit/wiki/AutoBean 您正在寻找GWT AutoBean： http : //code.google.com/p/google-web-toolkit/wiki/AutoBean

With AutoBeans you juset define the structure of your JSON and the GWT Compiler handles the rest. 使用AutoBeans，您可以通过juset定义JSON的结构，然后由GWT编译器处理其余部分。

I am writing this in comparison to using autobeans or GWT-RCP - if you are using Java on the server. 与使用autobeans或GWT-RCP相比，我正在编写此代码-如果您在服务器上使用Java。 Especially so, if you are not. 特别是，如果不是这样的话。

The cleanest way is REST-RPC/JPA, where you can share a single set of POJOS between client, server and persistence db. 最干净的方法是REST-RPC / JPA，您可以在其中在客户端，服务器和持久性数据库之间共享一组POJOS。 Let me brag on behalf of this technology mix - one single set of POJOs, instead of three, without any (or minimal) transformation between the three fronts. 让我代表这种技术组合来吹嘘-一组单独的POJO，而不是三个，在三个方面之间没有任何（或最少的）转换。

You should not have to write any data transformation routines. 您不必编写任何数据转换例程。 Or at least, only minimal amount of data transformation due to serialization constraints or because you are trying to interface GWT and REST with an existing schema which presents a high degree of non-serializability. 或至少由于序列化约束或由于您试图将GWT和REST与呈现高度不可序列化性的现有架构进行接口而导致的数据转换数量最少。

As well as, similar to GWT-RPC, sharing a single set of Java RPC methods on both client-server sides. 同样，类似于GWT-RPC，在客户端和服务器端共享一组Java RPC方法。 Well, nearly the same set of methods. 好吧，几乎相同的方法集。 Except that the return type on the server-side becomes the callback generic parameter on the client-side. 除了服务器端的返回类型成为客户端上的回调通用参数。

The mix of technology is: 技术组合为：

JAX-RS (either Resteasy or Jersey on the server side) JAX-RS（服务器端的Resteasy或Jersey）
JAX-RS + GWT = RestyGWT on the client-side 客户端上的JAX-RS + GWT = RestyGWT
JPA on the server-side 服务器端的JPA
JAXB over JAX-RS on both GWT client and server-side. GWT客户端和服务器端都通过JAX-RS进行JAXB。
Jackson JSON processor on server-side. 服务器端的Jackson JSON处理器。

Compelling reasons for REST-RPC is REST-RPC令人信服的原因是

you could pretend you writing client-server conversations as GWT-RPC. 您可以假装将客户端与服务器之间的对话编写为GWT-RPC。 The service interface and callback attitude is the same. 服务接口和回调态度是相同的。
The data interchange between client and server is in JSON. 客户端和服务器之间的数据交换采用JSON。
Which means you could use a browser instead of your GWT client to converse with the server after you have successfully set up your app. 这意味着在成功设置应用程序之后，您可以使用浏览器而不是GWT客户端与服务器对话。 Or jQuery. 或jQuery。 Or PHP, or Python as the server. 或PHP或Python作为服务器。
no need to muck around with the JSON or XML encode/decode yourself - deal in POJO and only in POJO. 无需自己弄乱JSON或XML编码/解码-仅在POJO中处理，而仅在POJO中处理。
you could use the browser to debug your web service independent of the GWT client. 您可以使用浏览器来调试独立于GWT客户端的Web服务。

The attitude of REST is (besides state independent requests) is the concept called a Web API. REST的态度是（除了独立于状态的请求外）是称为Web API的概念。 An API like a javadoc, perhaps - but stated in terms of JSON or XML. 可能像Javadoc这样的API-但用JSON或XML表示。 The wonderful thing about this API is - you do not have to generate the documentation. 关于此API的妙处是-您不必生成文档。 Like a javadoc, you could run Enunciate over the service interface. 像javadoc一样，您可以在服务接口上运行Enunciate。

You could follow my discussion in the following (3+ part) blog post: http://h2g2java.blessedgeek.com/2012/07/gwt-with-jax-rs-and-jpa-part-3.html . 您可以在以下（三部分）博客文章中关注我的讨论： http : //h2g2java.blessedgeek.com/2012/07/gwt-with-jax-rs-and-jpa-part-3.html 。