Consider that I'm using HTML for my REST API media-type, it could be JSON it doesn't matter.
HTML has a well understood <form> element with an action and a method. But if I'm posting to a resource location and I want to defend against concurrent updates the client will need to supply an If-Match.
It's not a given that the URL to which I'm posting can be retrieved with a GET or HEAD and therefore the client cannot get hold of the latest ETag.
I've noticed that neither HTML nor JSON Ion hypertext media-types, have support for an ifmatch or etag on the form.
It would negate the need for the client to try and then fail and then GET and then try again, or to GET another resource first or know and remember to keep hold of an ETag from another location.
Not sure if this an oversight or am I insane to be posting to resource locations that cannot be viewed.
The problem with posting to a viewable URL is the obvious extra code just really to support this situation.
And then if posting to a URL that exists and has some other utility, allows other stuff to be posted, then the "shape" of the incoming data must be distinguished in order to route to the correct handling code.
Seems like the whole thing would be much simpler with a prepopulated ifmatch in the form.
So, the question:
Should I design my hypermedia control (form) to have a prepopulated ifmatch element?
While typing this and framing in terms of HTML, I did some Googling and actually found a helpful resource.
http://amundsen.com/examples/put-delete-forms/
Mike proposes if-match and if-not-match in the HTML form!