REST API дизайн для обновления родительского узла в древовидной иерархии - PullRequest
Новая
       14

REST API дизайн для обновления родительского узла в древовидной иерархии

1 голос
/ 09 мая 2019

У меня есть три таблицы базы данных со следующей структурой: 

Country
id | name  

State
id | name | country_id

City
id | name | state_id

Существуют следующие URL-адреса конечных точек REST: 

/country                                                For list of all countries
/country/{country_id}                                   For a specific country
/country/{country_id}/state                             For list of all states in a country
/country/{country_id}/state/{state_id}                  For a specific state
/country/{country_id}/state/{state_id}/city             For list of all the cities in a state of a country
/country/{country_id}/state/{state_id}/city/{city_id}   For a specific city

Теперь у меня есть требование переместить один город изот одного состояния к другому, как мне спроектировать конечную точку REST для этой операции?Предложения.

1 Ответ

1 голос
/ 09 мая 2019

У меня есть требование перевести один город из одного штата в другой. Как мне спроектировать конечную точку REST для этой операции?

Насколько я могу судить, здесь нет хорошего ответа.

Обычно полезная эвристика - думать о том, как вы будете делать это на веб-сайте: вы загружаете какую-то форму, используете элементы управления вводом для описания ваших изменений, отправляете форму, а http-клиент POST формирует форму данные в некоторый URI, указанный сервером.

Так что эта часть достаточно проста - URI может быть «чем угодно», потому что клиенту все равно; он просто использует URI в форме.

Сервер получит сообщение и обработает его. Побочные эффекты, которые изменяют другие ресурсы, возможны по усмотрению сервера, так что все в порядке.

Но история с кешированием не очень хороша. Семантика запроса «переместить» город изменяет представления исходного состояния, целевого состояния, возможно, также самого города. Мы можем расположить форму так, чтобы любой из этих ресурсов был признан недействительным в результате успешного ответа (просто используя этот идентификатор в качестве цели запроса), но у нас нет какого-либо стандартизированного механизма для аннулирования других ресурсов.

Если бы вся древовидная иерархия была описана одним ресурсом, тогда не было бы никакой проблемы - это был бы единственный ресурс, который мы аннулировали.

(Представьте себе википедию - вы вносите изменения на страницу для Boston, и это также меняет страницу для Massachusetts. Не существует стандартного способа сообщить клиенту, что обе страницы изменились.)

...