REST - как создать URI с составными ключами?

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

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

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

GET фрахт? initialZipcode = {VALUE} & finalZipcode = {VALUE} & weight = {VALUE}

Ответ вышеописанной операции будет идентификатором фрахта, поэтому, наконец, они могут обновить информацию:

PUT фрахт /{ID}

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

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

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

PUT cargo/initialZipcode/{VALUE}/finalZipCode/{VALUE}/weight/{VALUE}

Я должен рассмотреть дизайн выше?

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

Спасибо!

ОТВЕТЫ

Ответ 1

Нет ничего плохого в

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

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

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

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

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

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

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

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