Блог

Главная - Вопросы по программированию - Как определить URL-адреса REST для дочерних объектов

Как определить URL-адреса REST для дочерних объектов

#rest

#rest

Вопрос:

У клиента может быть несколько адресов, я сомневаюсь в том, чтобы называть URL-адреса REST для адреса. CustomerAddresses — это отдельная таблица со ссылкой внешнего ключа на таблицу Customer.

Получает все адреса клиентов (HttpGet)

 /customers/{customerId}/addresses

Добавьте новый адрес клиента (HttpPost)

 /customers/{customerId}/addresses

Удалить адрес клиента (HttpDelete)

 /customers/{customerId}/addresses/{addressId}

(ИЛИ)

Получает все адреса клиентов (такие же, как указано выше)

 /customers/{customerId}/addresses

Добавьте новый адрес клиента (HttpPost), а тело включает идентификатор пользователя.

 /customeraddresses

Удалить адрес клиента (HttpDelete)

 /customeraddresses/{addressId}

Комментарии:

1. С технологической точки зрения второе решение вполне подходит, с точки зрения моделирования данных я бы использовал первое, поскольку «обычно» вы определяете идентификатор адреса клиента как составной ключ, ссылающийся на первичный ключ клиента, чтобы адрес не имел уникального идентификаторасам по себе

2. Что произойдет, если у вас есть другие объекты (кроме клиентов), у которых есть адреса? Что произойдет, если два клиента живут по одному адресу? Одна из идей может заключаться в том, чтобы иметь адреса в /adress/{addressId} и /customers/{customerId}/addresses возвращать кучу идентификаторов, которые затем требуют их поиска (или просто включают эти идентификаторы адресов в ответ от /customers/{customerId} . В противном случае я думаю, что ваш первый пример выглядит нормально.

3. Спасибо вам обоим, прямо сейчас они не являются автономными адресами и зависят от клиента. Я выбираю вариант 1.

Ответ №1:

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

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

Это может означать предпочтение

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

Часть пути URI является принципиально иерархической — может быть удобно выбирать варианты написания, которые позволяют использовать точечные сегменты для ссылки на другие ресурсы.

Имейте в виду, что ваша модель данных и ваша модель ресурсов — это разные вещи, и им должно быть разрешено меняться независимо. Если изменения в именах ваших таблиц также приводят к изменениям в написании идентификатора вашего ресурса, кому-то, где-то, вероятно, придется плохо.