由于多种原因 ，许多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”机制。
翻译自: https://www.javacodegeeks.com/2017/07/gwt-http-requests-alternatives.html
)
