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

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

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

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

вам Фрахт?initialZipcode={VALUE} & finalZipcode={VALUE} & weight={VALUE}

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

положить груз / {ID}

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

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

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

PUT Фрахт / initialZipcode / {VALUE} / finalZipCode / {VALUE} / вес / {VALUE}

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

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

спасибо!

16
composite-key design rest uri

1 ответов

нет ничего плохого с 

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

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

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

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

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

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

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

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

13