Лучшая практика REST для получения списка подмножеств

Question

Я прочитал статью на REST - сложные приложения , и она отвечает на некоторые мои вопросы, но не на все.

Я проектирую свое первое REST-приложение, и мне нужно вернуть списки «подмножеств» в GET-запросы. Что из перечисленного более «RESTful»?

/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

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

/patients;rounds=true;specific_id=xxxx;covering_id=yyyy;primary_id=zzzz

но для этого потребуется сложная логика ветвления, чтобы получить правильный список, в то время как запрос определенного подмножества (списка раундов) позволит добиться того же самого.

Обратите внимание, что мне нужно использовать параметры матрицы вместо параметров запроса, потому что мне нужно выполнять фильтрацию на нескольких уровнях URL. Используемая мной среда (RestEasy) полностью поддерживает параметры матрицы.

Answer 1

Ральф

конкретные шаблоны URI ортогональны вопросу о том, насколько RESTful будет ваше приложение.

В отношении RESTfulness важно то, что клиент обнаруживает , как создать URI во время выполнения . Это может быть достигнуто с помощью форм или шаблонов URI. Оба элемента управления гипермедиа сообщают клиенту, какие параметры можно использовать и где их поместить в URI.

Чтобы это работало RESTful, клиент и сервер должны знать возможные параметры во время разработки. Обычно это достигается путем включения их в спецификацию отношения ссылки.

Например, вы можете определить отношение ссылки «my-subset», чтобы иметь смысл связывания с подмножествами коллекций, и с его помощью вы бы определили следующие параметры:

listType, date, userID.

В шаблоне ссылки эта спецификация может использоваться как

Обратите внимание, как фактическое имя параметра в URI отделено от указанного имени параметра. Значение для userID привязано к параметру URI user_id с поздней привязкой.

Это позволяет изменять имя параметра URI, не затрагивая клиента.

Вы можете посмотреть описание документов OpenSearch (http://www.opensearch.org), чтобы увидеть, как это делается на практике.

На самом деле, вы должны иметь возможность использовать OpenSearch для вашего случая использования. В частности, возможность предопределения запросов позволит вам описывать определенные подмножества в ваших «формах».

Но посмотрите сами, а затем снова спросите: -)

Jan

Answer 2

Я бы порекомендовал вам использовать эту структуру URL:

/appointments;user_id=1234;date=2010-02-22

Почему? Я выбрал /appointments, потому что это просто и понятно. (Если у вас более одного вида встреч, дайте мне знать в комментариях, и я могу скорректировать свой ответ.) Я выбрал точку с запятой, поскольку они не подразумевают иерархию между user_id и датой.

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

/users/1234/appointments;date=2010-02-22

Чтобы вернуть похожий результат.

Тем не менее, я бы не рекомендовал использовать /dates/2010-02-22/appointments;user_id=1234. Зачем? На практике я не думаю, что /dates относится к ресурсу. Дата - это атрибут встречи, но она не является существительным сама по себе (то есть это не первоклассная вещь).

Answer 3

Я могу относиться к тому, что ответил Дэвид Джеймс.
Формат ваших URI может быть таким, как он предложил:

/appointments;user_id=1234;date=2010-02-22

и / или

/users/1234/appointments;date=2010-02-22

при сохранении возможности обнаружения (во время выполнения) URI вашего ресурса (как предложил Ян Альгермиссен).