Каков «правильный» и правильный способ сохранения функций API клиента Jersey и функций сервера REST (Jersey API)? - PullRequest
3 голосов
/ 11 июля 2011

Мне было интересно, как люди с большим опытом и более сложными проектами уживаются с этим "безобразием" в REST Communication.Представьте себе следующую проблему:

Нам понадобится достаточное количество функций для одного конкретного ресурса в нашей инфраструктуре REST, в моем случае это более 50 функций, которые приводят к разным запросам и разным ответам.Я попытался придумать значимое дерево ресурсов и назначил их методам, которые будут выполнять «вещи».Впоследствии класс ресурсов сервера выглядит следующим образом:

@Path("/thisResource")    
public class SomeResource {

    @GET/POST/PUT/DELETE
    @Path("meaningfulPath")
    public Response resourceFunction1 ( ...lots of Params) {

        ... logic ....

    }

//
// lots of functions ...
//

    @GET/POST/PUT/DELETE
    @Path("meaningfulPath")
    public Response resourceFunctionN ( ...lots of Params) {

    ... logic ....
    }
}

Чтобы создать URL, которые будет вызывать мой клиент, я сделал небольшую функцию для предотвращения опечаток и более эффективного использования констант

, поэтомумой клиент выглядит так:

public class Client() {
    public returnType function1 () {
        client.resource = ResourceClass.build(Constants.Resouce, "meaningfulPath");
        ...
        return response.getEntity(returnType);
    }

}

Теперь меня беспокоит вопрос, как мне лучше связать функцию клиента и функцию сервера?

Единственное соединение между этими двумя блоками кодаэто URL, который будет вызываться клиентом и отображаться сервером, и даже если этот URL генерируется где-то еще, это приводит к большой путанице.

Когда один из моих коллег должен войти в этокод, ему трудно понять, какая из 50+ клиентских функций приводит к какой функции сервера.Также трудно определить, есть ли в коде устаревшие функции и т. Д. Я думаю, что большинство из вас знает о проблемах нечистого кода лучше, чем я.

Как вы справляетесь с этим?Как бы вы сохранили этот код в чистоте, поддержке и великолепии?

Ответы [ 2 ]

3 голосов
/ 22 июля 2011

Обычно это решается EJB или подобными технологиями.

Или, по крайней мере, "реальными" веб-службами, которые предоставляют по крайней мере WSDL и схемы ( с видом сопоставления с интерфейсами Java или "портами" ).

Но REST-связь очень слабо набрана и слабо структурирована .

Единственное, о чем я могу думать сейчас: это определить проект (назовем его «Определения»), на который будет ссылаться (следовательно, известный ) клиентский и сервер. В этом проекте вы можете определить класс с большим количеством public static final String, например:

public static final String SOME_METHOD_NAME = "/someMethodName";
public static final String SOME_OTHER_METHOD_NAME = "/someOtherMethodName";

Примечание: на static final String очень хорошо может ссылаться аннотация (в этом случае компилятор считает ее постоянной). Поэтому используйте «константы» для аннотирования вашего @Path, например:

@Path(Definitions.SOME_METHOD_NAME)

То же самое для клиента:

ResourceClass.build(Constants.Resouce, Definitions.SOME_METHOD_NAME);
0 голосов
/ 04 октября 2012

Вы упускаете идею REST.То, что вы делаете, это не REST, а RPC через HTTP.Как правило, вы не должны создавать URL-адреса с использованием внешних знаний.Вместо этого вам следует переходить по ссылкам, полученным в ответах, полученных от сервера.Читайте о HATEOAS:

http://en.wikipedia.org/wiki/HATEOAS

...