По нескольким причинам многие пользователи GWT отказались от механизма RPC, который является стандартным способом, предлагаемым GWT для вызова внутреннего интерфейса. Они обнаружили, что потеряли себя между GWT RequestBuilder и другими внешними библиотеками, которые могут соответствовать или не соответствовать их модели приложения. Цель этого поста — просмотреть хорошо известные библиотеки HTTP / Rest в GWT, чтобы сделать картину более четкой. В этом посте мы протестируем библиотеки: RequestBuilder (часть GWT), RestyGwt , autorest -gwt и, наконец, Native XMLHttpRequest (JsInterop).
RequestBuilde r
RequestBuilder — это первое, что приходит на ум. Он является частью основных классов GWT и позволяет создавать и выполнять HTTP-вызовы. Реализация RequestBuilder использует JSNI для вызова собственного XMLHttpRequest в браузере. Недостатком RequestBuilder является обработка данных. Это полностью предоставлено пользователю, что требует дополнительной работы и может потребовать использования дополнительных библиотек, таких как gwt-jackson.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
try { request.sendRequest(null, new RequestCallback(){ @Override public 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 } @Override public void onError(Request request, Throwable exception) { } }); } catch (RequestException e) { e.printStackTrace(); } |
RestyGwt
RestyGWT является более комплексным решением, поскольку оно предлагает возможность отправлять и получать объекты, которые кажутся хорошей заменой RPC. RestyGwt работает так же, как и RPC: разработчик определяет интерфейсы, которые создаются во время компиляции, используя отложенное связывание. Это один из самых популярных GWT-проектов на Github. RestyGWT предлагает также несколько удобных функций, таких как диспетчеры, обработка JSONP, пользовательские аннотации и многое другое. Если разработчик хочет обойтись без стандартного шаблона создания интерфейсов, RestyGWT предлагает способ немедленного вызова конечных точек HTTP, но без сериализации / десериализации Json. Пример простого использования RestyGwt:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
public interface GuestService extends RestService { @GET public void get(MethodCallback<List<Guest>> callback);} public void onModuleLoad() { GuestService service = GWT.create(GuestService.class); service.get(new MethodCallback<List<Guest>>(){ @Override public void onFailure(Method method, Throwable exception) { GWT.log("Request Failed"); } @Override public void onSuccess(Method method, List<Guest> response) { response.forEach((g) -> {GWT.log(g.roomNumber);}); } }); } |
Недостатки RestyGwt в том, что он опирается на генераторы, которых не будет в следующей версии GWT 3.0. Нет никаких признаков того, что GWT 2.8.0 будет прекращено в то время, но есть уверенность, что разработчики, желающие перейти на 3.0, должны будут обходиться без RestyGwt, по крайней мере, на некоторое время.
autorest-GWT
autorest-gwt — интересный проект, использующий новые парадигмы, такие как потоки, для генерации интерфейсов служб Rest. autorest-gwt основан на rxjava-gwt, который является адаптацией RxJava к GWT. Для решения асинхронного аспекта HTTP-вызовов autorest-gwt использует Observable , который является объектом, на который вы можете подписаться, и как только результат будет готов, он уведомит вас. AutoRest также использует JsInterop для сериализации / десериализации объектов как из / в объекты Java / Js. Этот метод имеет преимущество в том смысле, что он не зависит от какой-либо внешней библиотеки, однако существуют некоторые ограничения для объектов, которые можно сериализовать ( сериализация JSON в GWT после разговора более подробно об этих ограничениях). Еще одним преимуществом autorest-gwt является то, что он использует процессоры аннотаций (вместо генераторов), что делает библиотеку более жизнеспособной в будущем.
|
01
02
03
04
05
06
07
08
09
10
11
12
|
@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 также является альтернативой для выполнения HTTP-вызовов со стороны клиента GWT. Этот метод немного низкого уровня, но он определенно позволяет разработчику получить контроль над всеми аспектами запросов / ответов. Например, предположим, что вы хотите установить тип ответа как большой двоичный объект или указать тип запроса как синхронный из-за особого требования, у вас нет возможности сделать это с помощью предыдущих библиотек, поскольку вы привязали их интерфейсы. Для обработки асинхронного аспекта HTTP можно использовать Promise , который является естественным способом указания действий, которые должны выполняться при разрешении запросов в Javascript. Наверняка проделана большая работа по сериализации / десериализации полезных нагрузок и объектов ответа, но этот метод дает свободу в каждом аспекте HTTP-запроса. Например:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
|
//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 librairies // there are other events such as progress, abort that are not available in other librairies nativeRequest.addEventListener("load", new Function() { @Override public Object call(JavaScriptObject event) { GWT.log(nativeRequest.responseText); return null; } }); nativeRequest.send(); |
другие
Существуют и другие библиотеки, которые не были рассмотрены, такие как Ajax GwtQuery , который на самом деле является просто интерфейсом поверх XMLHttpRequest, и RestDispatch GWTP, который опирается на GIN и который, как представляется, больше подходит для приложений, использующих GWTP. ,
Заворачивать
| Библиотека | Текущая версия | Pros | Cons |
|---|---|---|---|
| Построитель запросов | N / A | — основная библиотека GWT — нет шаблона, просто |
— сериализация / десериализация данных должна быть сделана разработчиком, доступен только ответ String / полезная нагрузка |
| RestyGWT | 2.2.0 | — сериализация / десериализация из коробки — Полезные функции: диспетчеры, JsonP, обработчики … |
— на основе генераторов — вопросы, связанные с Generics (более подробно о Github ) |
| AutoRest | 0,4 | — Использует процессоры аннотаций — Использует Observables (также может быть недостатком) |
— Котельная плита — Молодой проект, недостаточно зрелый — привязан к rxjava-gwt |
| Собственный XmlHttpRequest (JsInterop) | N / A | — Позволяет настраивать реализацию — Предоставляет доступ к параметрам API низкого уровня |
— необходимо знание API Javascript — обработка ответов / полезных нагрузок должна выполняться вручную |
Будущее понимание
HTTP-запросы — это то, что необходимо для современных веб-приложений, поэтому проект GWT должен предоставить своим пользователям надежный и легкий стандартный механизм для вызова HTTP-сервисов. В настоящее время пользователи GWT находятся в затруднительном положении, между тем, какая библиотека является полезной, и какая будет жизнеспособным выбором для будущего выпуска GWT 3.0. На данный момент разработчикам GWT лучше использовать собственные XmlHttpRequest и JsInterop, потому что именно этот метод обеспечивает лучший контроль над параметрами запроса. Разработчики GWT могут создавать свои собственные повторно используемые интерфейсы, и, возможно, в будущем появится шаблон. Другие структуры остаются модным выбором для тех, кто хочет быстро приступить к работе. Участники GWT могут получить вдохновение от таких проектов, как gRPC, для разработки следующего механизма RPC GWT.
| Ссылка: | GWT HTTP запрашивает альтернативы у нашего партнера по JCG Закарии Амине в блоге G-Widgets . |