Лучшая практика REST для получения списка подмножества
Я прочитал статью В ПОКОЕ - сложные приложения, и она отвечает на некоторые мои вопросы, но не все.
Я разрабатываю свое первое приложение REST и потребность возвратить списки "подмножества" для ПОЛУЧЕНИЯ запросов. Какое из следующего является БОЛЕЕ "УСПОКОИТЕЛЬНЫМ"?
/patients;listType=appointments;date=2010-02-22;user_id=1234
или
/patients/appointments-list;date=2010-02-22;user_id=1234
или даже
/appointments/2010-02-22/patients;user_id=1234
Будет приблизительно дюжина различных списков, которые я должен возвратить. В некоторых из них будет несколько параметров фильтрации, и я не хочу иметь большой, 'если' операторы в моем серверном коде для выбора подмножеств, на основе которых присутствуют параметры. Например, мне, возможно, понадобились бы все пациенты для определенного доктора, где закрывающий доктор - другой, и основной доктор является еще одним. Я мог выбрать с
/patients;rounds=true;specific_id=xxxx;covering_id=yyyy;primary_id=zzzz
но это потребовало бы, чтобы сложная переходящая логика получила правильный список, где просьба об определенном подмножестве (список раундов) достигнет той же самой вещи.
Обратите внимание, что я должен использовать параметры матрицы вместо параметров запроса, потому что я должен сделать фильтрацию на нескольких уровнях URL. Платформа я использую (RestEasy), полностью параметры матрицы поддержек.
3 ответа
1) Вы не можете и не должны управлять GC вручную.
2) Утилизация - это только индикация для GC, она в любом случае будет проходить, когда он чувствует себя правильно.: P
Единственный способ избежать этих проблем - профилировать ваше приложение и постараться как можно больше, чтобы избежать выделения новых объектов. Когда вы обнаружите, что происходит в сборщике мусора, попробуйте использовать некоторые методы объединения, чтобы повторно использовать эти данные и избегать их повторного создания каждый раз.
ПРАВКА: Каждый раз, когда GC выполняет ВСЕ потоки, он должен находиться в состоянии сна, чтобы позволить ему выполнять свою работу. Это причина замедления, если коллекций много, как в вашем случае. Для управления этим не существует другого способа, кроме сокращения генерации новых объектов.
-121--3504583-«Лишние» атрибуты влияют на порядок результата.
Рассмотрим:
create table gb (
a number,
b varchar(3),
c varchar(3)
);
insert into gb values ( 3, 'foo', 'foo');
insert into gb values ( 1, 'foo', 'foo');
insert into gb values ( 0, 'foo', 'foo');
insert into gb values ( 20, 'foo', 'bar');
insert into gb values ( 11, 'foo', 'bar');
insert into gb values ( 13, 'foo', 'bar');
insert into gb values ( 170, 'bar', 'foo');
insert into gb values ( 144, 'bar', 'foo');
insert into gb values ( 130, 'bar', 'foo');
insert into gb values (2002, 'bar', 'bar');
insert into gb values (1111, 'bar', 'bar');
insert into gb values (1331, 'bar', 'bar');
Эта инструкция
select sum(a), b, c
from gb
group by b, c;
приводит к
44 foo bar
444 bar foo
4 foo foo
4444 bar bar
, в то время как эта
select sum(a), b, c
from gb
group by c, b;
приводит к
444 bar foo
44 foo bar
4 foo foo
4444 bar bar
Ральф,
конкретные узоры URI ортогональны вопросу о том, каким образом RESTful будет ваше приложение.
Что важно в отношении RESTfulness, так это то, что клиент обнаруживает , как создать URI во время выполнения . Этого можно достичь с помощью форм или шаблонов URI. Оба элемента управления гипермедиа сообщают клиенту, какие параметры можно использовать и где их поместить в URI.
Для этого клиент и сервер должны знать возможные параметры во время проектирования. Это обычно достигается тем, что они становятся частью спецификации ссылки отношений.
Можно, например, определить связь «my-subset», чтобы иметь значение ссылки на подмножества коллекций, и с ее помощью определить следующие параметры:
listType, date, userID.
В шаблоне ссылки эта спецификация может использоваться как
< link rel = "my-subset 'template = "/{ listType }/{ date }/patives; user _ id = {userID} "/>
Обратите внимание на то, как фактическое имя параметра в URI отделено от указанного имени параметра. Значение для userID поздно привязано к параметру URI user_id.
Это делает возможным изменение имени параметра URI без влияния на клиента.
Можно просмотреть документы с описанием OpenSearch ( http://www.opensearch.org ), чтобы увидеть, как это делается на практике.
На самом деле, вы должны иметь возможность использовать OpenSearch довольно много для вашего случая использования. Особенно возможность предопределять запросы позволяет описывать определенные подмножества в «формах».
Но посмотрите сами и снова спросите: -)
Ян
Я бы порекомендовал вам использовать следующую структуру URL-адресов:
/appointments;user_id=1234;date=2010-02-22
Почему? Я выбрал / встречи , потому что это просто и понятно. (Если у вас несколько видов встреч, дайте мне знать в комментариях, и я смогу скорректировать свой ответ.) Я выбрал точки с запятой, потому что они не подразумевают иерархии между user_id и date.
И еще одно: нет причин, по которым вы должны ограничивать себя одним URL. Совершенно нормально иметь несколько структур URL-адресов, которые ссылаются на один и тот же ресурс. Так что вы также можете использовать:
/users/1234/appointments;date=2010-02-22
Чтобы вернуть аналогичный результат.
Тем не менее, я бы не рекомендовал использовать /ates / 2010-02-22 / assignments; user_id = 1234 . Почему? На практике я не думаю, что / date относится к ресурсу. Дата является атрибутом встречи, но сама по себе не является существительным (т. Е. Не является первоклассной вещью).
Я могу отнестись к тому, что ответил Дэвид Джеймс.
Формат ваших URI может быть таким, как он предложил:
/appointments;user_id=1234;date=2010-02-22
и / или
/users/1234/appointments;date=2010-02-22
при сохранении открываемости (во время выполнения) URI вашего ресурса (как предложил Ян Алгермиссен).