由于多種原因 ，許多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

總結

以上是生活随笔為你收集整理的GWT HTTP请求替代的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。