Can I have multiple link relations with the same URI in HATEOAS? -

i have resource, in case:

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

each sales representative has multiple products can sell. uri resource be:

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

the problem is, depending on user's permissions, might able get or get , put against resource.

my problem designing link relations when retrieving sales rep resource. example json follows:

{    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" }   ]  } 

if take approach, link relation named noun representing resource. doesn't communicate client whether can edit resource or not. far i'm aware http methods in links not part of spec & these responsibility of documentation, how communicate permissions?

    {        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" }       ]      } 

something work, making easy client create menu correct links based on presence of edit-products rel. curies 2 different rels link different sections in documentation, 1 get , put respectively. make sense? both approaches feel wrong me.

short answer yes, having same url behind different links comes quite often. worried has no simple answer, it's based on desired ux.

note view-products & edit-products not registered link relations (see http://www.iana.org/assignments/link-relations/link-relations.xhtml ) list, should uri's.

this important because it's common let uri's dereferenceable/hence urls contain documentation link relationship means. edit-products turned url eg http://example.com/rels/edit-products , retrieved result in documentation indicating can edited.

but find edit link @ level rather strange. there's few things edit here, product collection , individual products in collection. let's focus on latter first.

each product presumably resource, has it's own self link. if want change product developer it'd natural me put json representing product self link. don't need edit link because intent clear request. if i'm unable edit, should response indicating (and if it's on http appropriate http response code). if want remove product send delete url of self link. if wanted modify product might use patch request. if want more restrained editing capabilities, edit-form iana link relationship candidate, following return form used edit resource service intends/allows. , again have own uri relationship follows whatever conventions document. other consideration seem have want client know if can or cannot edit resource. if edit-form case it's easy having or not having relationship present. can use edit iana relationship indicate raw editing capabilities (and have same url self).

so think covers products, let's talk collection.

the ideas behind editing collection same if you've decided each product isn't it's own resource. put of product collection's self url imply adding product collection, while put of product collection self url replace entire collection. patch modify collection. on top of if had interesting cases user add product, not remove or reorder them, start dipping custom link relationships. again presence of relationships indicate client can , cannot done if need such functionality.

i might question why have products collection resource @ all. instead why not have product links off of sales rep:

{    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" }   ]  } 

again don't know whole model , ux, let edit sales rep resource add or remove products, while products stand alone own resources.

something isn't quite clear if intend edit-products return resource used editing products (like form). find useful think of json api html application (web site) web sites restful in nature. in html driven application case. ie on sales rep page (resource) you'd have link page (resource) allows user edit products. ditto viewing products. in such case these view product , edit products pages may same resource (ie it's same page lets view , edit), or different resources (ie 2 different pages 1 editing, 1 viewing). in former they'd have same url , in latter they'd have different urls. what's cool restful app can change without it's semantics changing. @ first might want them separate pages, 1 viewing 1 editing, different urls, might change mind , decide 1 page doing both appropriate. 2 link relationships have same url ui built on top of these relationships still functions correctly , transitions user desired resource.

there's other option (pun) have , that's submit options request self url. should give http methods available requesting user, such patch, put, post, delete, etc. collection of options can construct ui providing right ui controls. unfortunately requires roundtrip server, nice mechanism determine current client's allowed capabilities.

with bring important point. in general request method (and request whole) implies intent of client (update, delete, add, reset, patch, whatever) , service should interpret intent (as document possible intents) , decide fulfill request or not. approach , options request should not need have self link hierarchy relationships (eg: products) simple crud application