Каков наилучший способ реализовать вид getNext для результатов с помощью REST (рестлет) - PullRequest
Новая
       19

Каков наилучший способ реализовать вид getNext для результатов с помощью REST (рестлет)

0 голосов
/ 11 декабря 2011

Я пишу веб-сервис, который возвращает результаты.Эти результаты представляют собой некоторые данные, которые постоянно создаются на сервере.Поэтому, когда клиент запрашивает ресурс, я хочу дать ему также URL-адрес для следующего запроса, который он может выполнить, чтобы получить новые данные, созданные на сервере.Например, клиент может начать со следующего URL: 

http://ip:port/server/{id}/resource

, и в следующий раз он должен использовать что-то вроде: 

http://ip:port/server/{id}/resource/1234

, где 1234 - некоторый указатель на сервер, чтобы узнать, какой результатклиент уже получил.Итак, вопрос в том, где я могу вернуть URL к следующему набору результатов?это должно быть в шапке или в теле?Я прочитал некоторые ссылки об использовании параметров URL по сравнению с запросом, и если я понял, что для разбивки я лучше использовать URI, а не запрос.И последнее, мне нужно передать тело информации для запроса, и поэтому веб-сервис ожидает PUT, а не GET.Пример рестлета будет в основном оценен.

И последнее, у меня должно быть {id} в URL, но нет такого uri, как 

 http://ip:port/server

, так что будет правильнымдля пользователей знать там идентификатор?(результаты возвращаются по идентификатору пользователя).идентификатор назначен совершенно другим ресурсом.

1 Ответ

0 голосов
/ 16 марта 2012

Вы могли бы рассмотреть альтернативный подход с использованием условных GET.При таком подходе сервер отвечает на запросы GET заголовком ответа ETag и / или Last-Modified, чтобы указать, когда ресурс был последний раз изменен.Это будет "1234" в вашем примере выше.Затем клиент передает это значение в последующем GET тому же URI, что и ранее, предоставляя его в заголовке If-None-Match или If-Modified-Since.

У меня есть аналогичная служба, реализованная с использованием Restlet, которая постоянно получает обновления, и аналогичным образом клиенты хотят периодически получать информацию, более новую, чем та, которую они получали ранее.Я использую ETag.

В моем классе, производном от ServerResource, у меня есть код, подобный следующему: 

import org.restlet.data.Tag;
import org.restlet.representation.Representation;
import org.restlet.representation.Variant;

public class FooCollectionServerResource extends ServerResource implements FooCollectionResource {

    private Tag mResponseTag;

    @Override public FooCollection getFooCollection() {
        List<Tag> tags = getRequest().getConditions().getNoneMatch();
        Tag eTag = null;
        if (!tags.isEmpty())
            eTag = tags.get(0);

        // might be an empty collection, if there are no new/modified Foos since eTag
        FooCollection result = getFoosSince(eTag); 

        mResponseTag = new Tag("1234"); // hardcoded here, but you get the idea
        return result;
    }


    @Override
    public Representation toRepresentation(final Object source, final Variant target) {
        Representation result = super.toRepresentation(source, target);
        result.setTag(mResponseTag);
        return result;
    }
}

Одна хитрость в том, что вы не можете установить значение заголовка ETag непосредственно в getFoo() метод;Вы должны убрать его в поле и использовать в переопределении toRepresentation ().Это связано с тем, что в Restlet создается ответное представление.

...