2015-03-30 2 views
0

У нас есть ресурсы на нескольких уровнях вложенности. На одном из уровней ресурсы, отображаемые в части пользовательского интерфейса, веб-страница - это просто уникальные значения String для некоторых ее свойств.Как создать REST API для ресурсов, не управляемых идентификаторами

Для примера: не реальный пример, но у нас есть случай что-то вроде этого:

Университет имеет факультеты, кафедры обучаются студенты каждый с адресной строкой, и у нас есть интерфейс, которые показывают уникальные адреса студентов для данного университета и отдела. В пользовательском интерфейсе нет такого имени, как id, для которого мы можем проектировать службы отдыха, подобные этому.

Получить один: GET university/{uniId}/deptartment/{deptId}/address/{adId}

Получить все: GET university/{uniId}/deptartment/{deptId}/address

Добавить: POST university/{uniId}/deptartment/{deptId}/

Редактировать существующий: PUT university/{uniId}/deptartment/{deptId}/address/{adId}

Удалить: DELETE university/{uniId}/deptartment/{deptId}/address/{adId}

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

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

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

До сих пор, что мы сделали это

Получить все: GET university/{uniId}/deptartment/{deptId}/address который получает все уникальные адреса для данного

Добавить: POST university/{uniId}/deptartment/{deptId}/address с новым значением адреса в качестве тела запроса.

Для редактирования (PUT) нам нужно передать старое значение, а также новое значение, а для DELETE нам нужно передать старое значение адреса.

Но тогда запросить тело для DELETE это не очень хорошая идея.

Итак, как мы должны разрабатывать URL-адреса и органы запроса для редактирования и удаления.

Любые предложения более чем приветствуются.

ответ

0

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

Для меня это означает, что этот адрес является отдельным объектом, а не дочерним элементом какого-либо другого объекта. REST не так хорош в выражении чего-то, что выходит из простого отношения между родителями и родителями. Таким образом, адрес должен получить собственный URL-адрес для управления. И вы придумаете способ связать адреса с другими объектами.

  • GET /address?university={uniId}&deptartment={deptId} - читать адреса (каждый фильтр может быть опущен, чтобы получить список адресов, &adId={adId} могут быть добавлены, чтобы получить только один адрес, идентификатор

  • POST /address/{adId}/link/?university={uniId}&deptartment={deptId}. - адрес ссылки на любые объекты вы хотите

Таким образом, каждый объект управляется отдельно. И вы можете использовать DELETE методы всем, включая адресные ссылки, я думаю.

Смежные вопросы