REST - как дизайн URI с составными клавишами?

Question

У меня вопрос о том, как дизайн ресурса URI с составными ключами.

У меня есть ресурс, называемый грузом, который имеет 4 ключа/идентификаторы: идентификатор партнера, начальный индекс, окончательный индекс и вес.

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

?

GET грузовой initialZipcode = {VALUE} & finalZipcode = {VALUE} & вес = {VALUE}

отклик операции выше будет груз ID, так что, наконец, они могут обновить информацию:

PUT фрахт/{ID}

Идентификатор партнера подразумевается механизмом аутентификации.

Для меня кажется странным заставить партнеров получить идентификатор фрахта перед обновлением информации.

Так что мой вопрос: как я могу создать этот URI?

PUT грузовой/initialZipcode/{VALUE}/finalZipCode/{VALUE}/вес/{VALUE}

ли я рассмотреть вопрос о разработке выше?

Другой вопрос: является ли хорошая практика встроенным партнером в механизм аутентификации? Я знаю плюсы (простые для потребителей) и минусы (кеш, невозможность обмена URI и т. Д.), Но я не знаю, является ли вообще хорошей или плохой практикой.

Спасибо!

Answer 1

Там нет ничего плохого с

PUT freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE} 

параметры запроса являются частью идентификации ресурсов тоже.

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

Единственная проблема заключается в том, что делать, когда клиент повторно упорядочивает параметры запроса. Вы относитесь к нему как к одному и тому же ресурсу, или вы 404? Если вы не кешируете ответы GET, это, вероятно, не имеет значения.

Если вы предоставили своему клиенту шаблон URI для их заполнения, то есть меньше шансов, что они дадут вам параметры в неправильном порядке.

---

Другой вариант, если вы идете с оригинальным предложением в том, что ваш GET возвращает редирект и расположение заголовка к URI с грузовым ID. например

GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE} 
=> 
302 See Other 
Location: freight/1232321322 

Делая это, ваш клиент не должен ничего знать о грузовых ID, он может просто захватить заголовок местоположения, а также следить за редирект сделать GET, или сделать PUT непосредственно против любой URI находится в заголовке Location.Это означает, что если вы решите, что вам не нравится выставлять идентификатор в будущем, вы можете изменить URI, не нарушая никаких клиентов.