Is there any possibility to define headers?

[wertzui]

Is it possible to define required headers which need to be send along with the request using HAL-Forms?

Examples would be

• Authorization where a Bearer Token needs to be send along
• Accept with the possible MIME types the server can respond with
• If-None-Match for caching and concurrency detection

[mamund]

there are not unique headers defined by this spec. also, HAL-FORMS is not designed to require authorization, etc.

however, section 6.2 refers to contentType but does not explicitly mention the header -- we could improve that text, i think.

as for other HTTP headers not directly related to HAL-FORMS, i don't think it is a good idea to bake them in the HAL-FORMS spec itself. These are covered well elsewhere: HTTP spec (https://tools.ietf.org/html/rfc7231), IANA Message Headers (https://www.iana.org/assignments/message-headers/message-headers.xhtml), etc.

does that make sense? are there other things you had in mind?

[evert]

Not sure if this helps, but link hints has:

1. auth-schemes, which addresses the bearer token case. It basically gives you a way to indicate that a link is probably going to require auth. Alternatively you can optimistically do a request and just see if you get a 401 back.
2. formats, addressing your second request. Alternatively you can do an OPTIONS request.
3. precondition-req, addressing your concurrency detection point. Alternatively you could also do the request optimistically here and wait for a 428 error. This doesn't suggest anything about caching, but if you have an ETag you got form an earlier request, you should use it always!

link-hints can be integrated with HAL links. (we did and it works well). I don't think it integrates as well with HAL Forms unfortunately. This is mostly because HAL forms' target is a URL and not a HAL link.

[obfuscoder]

I would love to see some progress on at least the Accept header part as this is something we use heavily in our REST APIs.