gwt格式_GWT HTTP请求替代方案

gwt格式

由于多种原因，许多GWT用户放弃了RPC机制，这是GWT提供的调用后端的标准方法。他们发现，在GWT RequestBuilder与其他可能不适合其应用程序模型的外部库之间迷失了自己。这篇文章的目的是要通过GWT中众所周知的HTTP / Rest库来尝试使情况更清晰。在这篇文章中，我们将测试的库是： RequestBuilder （GWT的一部分）， RestyGwt ， autorest -gwt ，最后是本机XMLHttpRequest （JsInterop）。

RequestBuilde

首先想到RequestBuilder。它是核心GWT类的一部分，并允许构建和执行HTTP调用。 RequestBuilder的实现利用JSNI在浏览器中调用本机XMLHttpRequest。 RequestBuilder的缺点是正在处理数据。它完全留给用户，需要其他工作，并且可能需要使用其他库，例如gwt-jackson。

RequestBuilder request = new RequestBuilder(RequestBuilder.GET, "http://localhost:8085/guest");try {request.sendRequest(null, new RequestCallback(){@Overridepublic void onResponseReceived(Request request, Response response) {GWT.log(response.getText());// You get the response as a String so more processing required to convert/extract data}@Overridepublic void onError(Request request, Throwable exception) {}});} catch (RequestException e) {e.printStackTrace();}

RestyGwt

RestyGWT是一种更全面的解决方案，因为它提供了发送和接收对象的功能，这似乎可以很好地替代RPC。 RestyGwt与RPC的工作方式相同：开发人员使用延迟绑定定义在编译时生成的接口。它是Github上最受欢迎的GWT项目之一。 RestyGWT还提供了一些方便的功能，例如分派器，JSONP处理，自定义注释等。如果开发人员希望没有创建接口的样板，RestyGWT提供了一种直接调用HTTP端点的方法，而无需Json序列化/反序列化。简单的RestyGwt用法示例如下：

public interface GuestService extends RestService {@Path("http://localhost:8085/guest")@GETpublic void get(MethodCallback<List<Guest>> callback);}public void onModuleLoad() {GuestService service = GWT.create(GuestService.class);service.get(new MethodCallback<List<Guest>>(){@Overridepublic void onFailure(Method method, Throwable exception) {GWT.log("Request Failed");}@Overridepublic void onSuccess(Method method, List<Guest> response) {response.forEach((g) -> {GWT.log(g.roomNumber);});}});}

RestyGwt的缺点在于它依赖于Generators，而Generators不会在下一个GWT 3.0版本中提供。没有迹象表明GWT 2.8.0届时将停止使用，但可以肯定的是，愿意升级到3.0的开发人员必须至少在一段时间内没有RestyGwt。

汽车休息

autorest-gwt是一个有趣的项目，它利用诸如流之类的新范例来生成Rest服务接口。 autorest-gwt基于rxjava-gwt ，它是RxJava对GWT的改编。为了解决HTTP调用的异步方面，autorest-gwt使用Observable ，这是一个您可以订阅的对象，一旦结果准备好，它将立即通知您。 AutoRest还使用JsInterop来对对象进行序列化/反序列化，作为Java / Js对象的来源。此方法的优势在于它不依赖任何外部库，但是对可序列化的对象有一些限制（ GWT中的JSON序列化将在更多关于这些限制的详细信息中进行讨论）。 autorest-gwt的另一个优点是它使用注释处理器（而不是Generator），这使该库在将来更可行。

@AutoRestGwt @Path("guest") interface GuestService2 {@GET Observable<Guest> get();}static ResourceVisitor osm() { return new RequestResourceBuilder().path("http://localhost:8085/"); }public void onModuleLoad() {GuestService2 gs = new GuestService2_RestServiceModel(() -> osm());gs.get().subscribe(n -> {GWT.log(n.guestId+"");});}

autorest-gwt仍然是一个年轻的项目。它的版本是0.x（到目前为止有4个发行版），并且还需要一些时间才能成熟。 autorest-gwt还引入了一些样板代码，但仍可管理。

本机XMLHttpRequest（JsInterop）

在GWT客户端，所有以前的库都可以归结为本地XMLHttpRequest，唯一不同的是XMLHttpRequest的包装方式。

自从引入JsInterop以来，事情可以有所不同。开发人员可以像使用Java类一样使用本机浏览器功能。直接使用本机XMLHttpRequest也是从GWT客户端进行HTTP调用的一种替代方法。这种方法有点低级，但是它绝对允许开发人员获得对请求/响应各个方面的控制。例如，假设由于特殊要求，您希望将响应类型设置为Blob，或将请求类型指定为同步，那么您将无法使用以前的库来这样做，因为您将它们的接口绑定在一起。为了处理HTTP的异步方面，可以使用Promise ，它是在请求以Java脚本解析时指定要采取的措施的自然方法。当然，在有效负载和响应对象的序列化/反序列化方面还有更多工作要做，但是此方法允许HTTP请求的各个方面都具有自由度。例如：

//Implemented using JsInterop, can also be used from Elemental 2 private final XMLHttpRequest nativeRequest = new XMLHttpRequest();//false means that the request is synchronous which can not be done in other librairiesnativeRequest.open("GET", "http://localhost:8085/guest", false);// there are other events such as progress, abort that are not available in other librairiesnativeRequest.addEventListener("load", new Function() {@Overridepublic Object call(JavaScriptObject event) {GWT.log(nativeRequest.responseText);return null;}});nativeRequest.send();

其他

有没有被覆盖，如其他librairies GwtQuery的阿贾克斯是在现实中只是XMLHttpRequest的顶部的inteface，并GWTP的RestDispatch依赖于GIN和似乎更适合于各种应用，利用GWTP的。

结语

图书馆	当前版本	优点	缺点
请求生成器	不适用	–核心GWT库 –无样板，简单	–数据的序列化/反序列化必须由开发人员完成，只有字符串响应/有效负载可用
RestyGWT	2.2.0	–开箱即用的序列化/反序列化 –有用的功能：调度程序，JsonP，处理程序…	–基于发电机 –与泛型有关的问题（有关Github的更多详细信息）
自动休息	0.4	–使用注释处理器 –使用可观察物（也可能是一个缺点）	–样板 –年轻的项目，还不够成熟 –绑定到rxjava-gwt
本机XmlHttpRequest（JsInterop）	不适用	–允许自定义实施 –允许访问低级API选项	–需要Javascript API的知识 –处理响应/有效载荷需要手动完成

未来见解

HTTP请求对于现代Web应用程序是必不可少的，因此GWT项目需要为其用户提供一种可靠且轻松的标准机制来调用HTTP服务。当前，GWT用户在哪个库有用和哪个库将是未来GWT 3.0发行版的可行选择之间处于困境。目前，GWT开发人员最好使用本机XmlHttpRequest和JsInterop，因为它是对请求选项提供最佳控制的方法。 GWT开发人员可以创建自己的可重用接口，并且将来可能会出现一种模式。对于那些希望快速启动并运行的框架，其他框架仍然是不错的选择。 GWT贡献者可能会从gRPC等项目中获得灵感，以设计下一个GWT“ RPC”机制。