Могу ли я иметь несколько связей ссылок с тем же URI в HATEOAS?

Question

У меня есть ресурс, в данном случае:

http://www.domain.com/sales-rep/{id} 

Каждый торговый представитель имеет несколько продуктов, которые они могут продать. URI для этого ресурса будет:

http://www.domain.com/sales-rep/{id}/products 

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

Моя проблема заключается в разработке связей ссылок при получении ресурса репрезентации продаж. Например мой JSON может выглядеть следующим образом:

{ 
    firstname : "Dave", 
    lastname : "Matthews", 
    links : [ 
    { rel : "self", href : "http://www.domain.com/sales-rep/dmat1" }, 
    { rel : "products", href : "http://www.domain.com/sales-rep/dmat1/products" } 
    ] 
} 

Если взять такой подход, моя ссылка соотношение хорошо назван в качестве существительного, представляющего ресурс. Однако он не сообщает клиенту, могу ли я редактировать ресурс или нет. Насколько я знаю, HTTP-методы в ссылках не входят в спецификацию &, это ответственность за документацию, поэтому как мне сообщить разрешения?

{ 
     firstname : "Dave", 
     lastname : "Matthews", 
     links : [ 
     { rel : "self", href : "http://www.domain.com/sales-rep/dmat1" }, 
     { rel : "view-products", href : "http://www.domain.com/sales-rep/dmat1/products", 
     { rel : "edit-products", href : "http://www.domain.com/sales-rep/dmat1/products" } 
     ] 
    } 

Что-то подобное может работать, что делает его легким для клиента, чтобы создать меню с правильными ссылками на основе наличия edit-products отн. Кюри для двух разных отложений затем будут ссылаться на различные разделы документации, один для GET и PUT соответственно. Но имеет ли это смысл? Оба подхода мне не нравятся.

Answer 1

Короткий ответ - да, с тем же URL-адресом за разными ссылками возникает довольно часто. Но то, о чем вы беспокоитесь, не имеет простого ответа, оно полностью основано на желаемом UX.

Отметьте, что просмотр-продукты & edit-products не являются зарегистрированными связями (см. http://www.iana.org/assignments/link-relations/link-relations.xhtml) для этого списка, поэтому они должны быть URI.

Это важно, потому что очень часто допускается, чтобы эти URI были разыменовываемыми/следовательно URL-адресами, которые фактически содержат документацию о том, что означает связь ссылок. Таким образом, ваши редакционные продукты превратились в URL-адрес, например http://example.com/rels/edit-products, и извлечение может привести к документации, указывающей, что можно редактировать.

Но я бы нашел ссылку редактирования на этом уровне, чтобы быть довольно странной. Как правило, есть несколько вещей, которые вы можете редактировать здесь: сбор продуктов и отдельные продукты в коллекции. Давайте сначала сосредоточимся на последнем.

Каждый продукт, предположительно, является ресурсом, поэтому у него есть собственная связь. Если я хочу изменить этот продукт в качестве разработчика, для меня было бы естественным ПОПРАВИТЬ некоторый JSON, представляющий продукт для собственной ссылки. Мне не нужна ссылка для редактирования, потому что мое намерение ясно с моей просьбой. Если я не могу редактировать, тогда я должен получить ответ, указывающий на это (и если он соответствует http-адресу соответствующего кода ответа HTTP). Если я хочу удалить этот продукт, я могу отправить DELETE в URL-адрес собственной ссылки. Если бы я хотел модифицировать продукт, я мог бы использовать запрос PATCH. Если вы хотите более ограниченные возможности редактирования, то связь с каналом IANA формы редактирования будет хорошим кандидатом, после чего будет возвращена форма, используемая для редактирования ресурса по мере того, как служба намеревается/разрешает. И снова у вас может быть собственное отношение URI, которое следует за любыми соглашениями, которые вы документируете. Другое соображение, которое, как вам кажется, заключается в том, что вы хотите, чтобы клиент знал, может ли он или не может редактировать ресурс. Если вы делаете дело с формой редактирования, это так же просто, как наличие или отсутствие наличия этих отношений.Вы также можете использовать изменение отношения IANA для указания возможностей редактирования (и он может иметь тот же URL-адрес, что и я).

Так что я думаю, что покрывает продукты, давайте поговорим о коллекции.

Идеи, связанные с редактированием коллекции, одинаковы, даже если вы решили, что каждый продукт не является его собственным ресурсом. PUT продукта к собственному URL-адресу коллекции будет означать добавление продукта в коллекцию, в то время как PUT коллекции продуктов на собственный URL-адрес заменит всю коллекцию. PATCH изменит коллекцию. Кроме того, если у вас были интересные случаи, когда пользователь мог добавлять только продукт, но не удалять или изменять его порядок, я бы начал погружаться в пользовательские связи ссылок. Опять же, наличие отношений может указывать клиенту, что может и не может быть сделано, если вам нужна такая функциональность.

Я могу рассказать, почему у вас есть ресурс для сбора продуктов. Вместо этого, почему нет ссылок на продукты прочь отдел продаж:

{ 
    firstname : "Dave", 
    lastname : "Matthews", 
    links : [ 
    { rel : "self", href : "http://www.domain.com/sales-rep/dmat1" }, 
    { rel : "product", href : "http://www.domain.com/product1" }, 
    { rel : "product", href : "http://www.domain.com/product2" }, 
    { rel : "product", href : "http://www.domain.com/product3" }, 
    { rel : "product", href : "http://www.domain.com/product4" } 
    ] 
} 

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

Что-то, что не совсем понятно, если вы хотите, чтобы редактируемые продукты возвращали ресурс, используемый для редактирования продуктов (например, формы). Мне часто очень полезно думать о моем JSON api, так же как и в моем приложении HTML (веб-сайте), поскольку веб-сайты очень RESTful по своей природе. В приложении с поддержкой HTML это, вероятно, будет так. IE на странице продаж (ресурс) у вас будет ссылка на страницу (ресурс), которая позволяет пользователю редактировать свои продукты. так же, как и просмотр продуктов. В таком случае эти страницы просмотра продукта и редактирования могут быть одним и тем же ресурсом (IE это та же самая страница, которая позволяет просматривать и редактировать), или разными ресурсами (IE две разные страницы, которые только для редактирования, только для просмотра). В первом они, вероятно, имели бы тот же URL-адрес, и в последнем они имели бы разные URL-адреса. Что круто в RESTful, так это то, что ваше приложение может измениться без изменения семантики. Сначала вы можете захотеть, чтобы они были отдельными страницами, один для просмотра одного для редактирования, поэтому они представляют собой разные URL-адреса, но тогда вы можете передумать и решить, что одна страница для обоих подходит. теперь два отношения связей имеют один и тот же URL-адрес, но любой пользовательский интерфейс, построенный поверх этих отношений, все еще функционирует правильно и переводит пользователя на нужный ресурс.

Есть еще один другой вариант (каламбур), который у вас есть, и это отправить запрос OPTIONS на собственный URL-адрес. Это должно предоставить доступным HTTP-методам запрашивающему пользователю, таким как PATCH, PUT, POST, DELETE и т. Д. Из этой коллекции опций, вы можете создать пользовательский интерфейс, обеспечивающий правильные элементы пользовательского интерфейса. Это, к сожалению, требует дополнительного обратного перехода к серверу, но это очень хороший механизм для определения возможностей текущего клиента.

С этим я поднимаю самый важный момент. В общем случае метод запроса (и запрос в целом) подразумевает намерение клиента (обновлять, удалять, добавлять, перезаписывать, исправлять, что угодно), и служба должна интерпретировать это намерение (а также возможные документы) и решать выполнить запрос или нет. При таком подходе и запросе OPTIONS вам обычно не нужно иметь ничего, кроме ссылки SELF, отношения иерархии (например: продукты) для простого приложения CRUD.