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

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

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

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

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

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

И последнее, я должен иметь {id} в URL-адресе, но такого uri, как

 http://ip:port/server

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


http java rest put restlet
person Sophie    schedule 11.12.2011    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Вы можете рассмотреть альтернативный подход с использованием условных 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.

person Andy Dennie    schedule 16.03.2012