Provide separate REST API schemas for CRUD and by context

[johnbillion]

The REST API schemas provided currently are only valid for reads (GET) and for the view and edit contexts. This has some problems:

• The schemas aren't valid if you're trying to construct a create, update, or delete request
• The schemas have fewer constraints than they should have for both the view and edit contexts as they currently cover both
• The schemas are not valid for the embed context

Ideally separate schemas would be provided for each of the four request types (CRUD) and each of the three contexts (view, edit, and embed).

What I don't want to do though is maintain a bunch of schemas for each endpoint that are all similar. This needs to either use partials or be automated somehow.

[johnbillion]

Perhaps the entire set of REST API schema files need to be generated from OPTIONS requests to the actual endpoints, and this library provides transformation rules on a per-endpoint basis for adjustments.

[johnbillion]

For naming conventions, the HTTP verbs can't be used because POST can be used for both creating and updating.

• Create: POST
• Read: GET
• Update: POST, PUT, PATCH
• Delete: DELETE

[johnbillion]

Actually that might not be true, because to create an entity you POST to the collection endpoint and to update an entity you POST to the single item endpoint, and these have different schemas (although currently the collection schema is just an array of the single schemas).