Блог

У меня есть ресурс с идентификатором id и именем атрибута — имя уникально для каждого из экземпляров ресурса.

Совместимо ли с REST и JSON: API использование поля name в качестве идентификатора в URL-адресе для получения, исправления и удаления ресурса?

например, чтобы получить ресурс по имени, соответствует ли следующий URL-адрес:

GET /resource/{name}

или следует использовать / предпочтительнее следующее:

GET /resource?name={name}

для исправления или удаления по имени можно использовать:

PATCH /resource/{name}

УДАЛИТЬ /ресурс/{имя}

Совместимо ли с REST и JSON: API использование поля name в качестве идентификатора в URL-адресе для получения, исправления и удаления ресурса?

Да. REST не волнует, какие варианты написания вы используете для своих идентификаторов ресурсов, если эти идентификаторы соответствуют правилам производства, определенным в RFC 3986.

Это может означать, что вам нужно закодировать имя атрибута — например, заменить некоторые зарезервированные символы эквивалентным шестнадцатеричным представлением.

 GET /resource/{name}
PATCH /resource/{name}
DELETE /resource/{name}
  

Это нормально

 GET /resource?name={name}
PATCH /resource?name={name}
DELETE /resource?name={name}
  

Тоже хорошо. Это компромисс; кодирование информации в сегменты пути означает, что вы можете воспользоваться относительными ссылками и точечными сегментами. Использование пар ключ-значение в части запроса означает, что вы можете использовать HTML-формы, позволяющие клиенту указывать имя.

 GET /resource?name={name}
DELETE /resource/{name}
  

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

Этот ответ полностью игнорирует, что он также должен соответствовать спецификации JSON API.

Это справедливый комментарий.

Спецификация JSON: API не вводит каких-либо существенных ограничений на соглашения о правописании, используемые в URI.

Однако ожидается, что идентификаторы могут быть расширены с помощью пар значений ключа application / x-www-form-urlencoded для поддержки сортировки, разбивки на страницы, фильтрации и так далее.

(Предупреждение: пожалуйста, будьте осторожны при чтении спецификации JSON: API, поскольку использование «ресурса» там не очень хорошо согласуется со значением ресурса в контексте REST.)

Рекомендации JSON: API для проектирования URI поощряют использование сегментов пути для ссылки на «ресурсы», как если бы они были индивидуально адресуемыми иерархически организованными элементами одного «справочного документа».

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

 /{type}/{id}
  

Другими словами, GET /resource/{name} должно возвращать application/vnd.api json представление с type членом resource и id членом name . Спецификация применяет дополнительное ограничение, заключающееся в том, что эта комбинация (тип, идентификатор) должна быть уникальной.

Если name это просто свойство, а не фактически идентификатор, то JSON: API рекомендует рассматривать его как фильтр

 /resource?filter[name]=abcde
  

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

(Примечание: [] являются разделителями RFC 3986 и, следовательно, требуют шестнадцатеричной кодировки в части запроса. По крайней мере, один из примеров JSON: API содержит поясняющее примечание, но пример фильтрации в рекомендациях не подчеркивает этого. На практике? вам может сойти с рук их использование в незашифрованном виде — использование квадратных скобок в части запроса было обычным несоответствующим соглашением).