Submitting forms

Using forms is about allowing the API to describe to the client what the client needs to send back in its request. What the form has is beyond this part of the tutorial but at this stage the simple answer is that the guidelines of HTML semantics are used. Rather this tutorial describes how we wire up the rules of what a form contains.

Some key guidelines

  • edit-form is a PUT
  • create-form is a POST
  • search is POST (because it is just a create)
  • submit may be present on a form and should be used for submission when present
  • self of the form should never be used
  • self of the originating resource can be used when submit on the form is not present
  • a form can override a verb by including a ‘type’ on the submit

Remember, that the designer of the API is

  • unlikely have an edit-form on collection (you add/remove items to a collection rather than update the collection per se)
  • unlikely to have a create-form on a collection item
  • unlikely to see a create-form on singleton (the edit-form will have attributes that allow adding/removing)
Unlock the next chapter
The semantics of form submission are
Following what the form says
A cascading set of known decision points to get to an end goal
An optimisation strategy
Throwing away everything HTTP was figuring out for the last 20 years