Description
Some of the concerns I have raised in issue #48 are motivated by an assumption that JSON Hyper-Schema should be usable to describe any HTTP API, including those that abuse HTTP. Is this a goal, or is full and proper use of HTTP a prerequisite for being able to create a usable hyper-schema?
We can complain about it as much as we want (and I often do), but many real-world HTTP APIs abuse the HTTP spec. People still write APIs that tunnel everything through POST. They don't set Accept-Patch when they're using PATCH. They implement partial updates with PUT. Or POST.
In order to support these APIs, JSON Hyper-Schema would need ways to explicitly map operations to HTTP methods, requests, and responses. Specifically method (or some other keyword) would need to allow specifying the actual HTTP (or other protocol) method to be used, along with using schema to describe non-standard request formats such as PUT requests that are not proper representations.
The "get"/"set"/"create"/"delete" links in the alternate format that I'd used in the past (which puzzled @awwright in issue #48 ) were never (intentionally) used to override HTTP behavior in newly designed APIs. But they did allow using the same tooling with old APIs, some of which may not have used HTTP fully or correctly.
Being able to retrofit legacy APIs with JSON Hyper-Schema to allow them to be used in the same tooling ecosystem seems very desirable to me to facilitate adoption.