rest - Is there a standard way to define CURIEs in HTTP header fields? -


recently, i've designing restful api, , want use link header field implement hateoas.

this fine , works without real problem, want make easier clients of api.

the link header example might this:

link: <https://api.domain.com/orders/{id}>; rel="https://docs.domain.com/order"

in case client have find link searching https://docs.domain.com/order value in rel attribute.

this works, since uri docs change it's fragile, , because of length makes bit impractical key search for.

so want try , use curie make instead:

link: <https://api.domain.com/orders/{id}>; rel="[rc:order]"

that way problem of uri changing mitigated part, , it's more compact allowing easier search client.

my problem is, since i'm using link header field implement hateoas feel consistent include curie http header field, rather introducing meta data in response body.

since entire api uses standard http header fields , status codes of it's meta data (pagination, versioning etc), rather not introduce meta data response body define curie.

but if use http header fields, field should use curie?

is there standard way http header fields?

if not, should use custom header field, x-curie: <https://docs.domain.com>; name="rc", , document somewhere clients?

i've looked around , resources either in reference xml or hal standard, information on in relation http header fields appreciated.

no, can't that. link relation string - nothing more.

the question should ask why using unstable link relation name in first place...


Comments

Popular posts from this blog

php - How to display all orders for a single product showing the most recent first? Woocommerce -

asp.net - How to correctly use QUERY_STRING in ISAPI rewrite? -

angularjs - How restrict admin panel using in backend laravel and admin panel on angular? -