DEV Community

Discussion on: OHM, the mediatype for REST/HATEOAS powered by OpenAPI

 
benniecopeland profile image
Bennie Copeland

Sorry but I can't agree with that. HATEOAS provides affordances through links dynamically at runtime, not statically at client implementation.

I agree with that. What I was trying to say is that the client still needs to be able to understand what those opaque links represent by knowing at implementation time the set possible of link relations it MIGHT encounter. Not that it's preprogrammed with the workflow steps/navigation, but if it sees a "next" or "user-disable" link relation, it knows how to proceed/present that affordance to the user.

OHM supports all types of operation, can describe forms, etc

I must have missed this piece, is OHM meant for documentation or are you proposing it as an implementation hypermedia type?

Thread Thread
 
cbornet profile image
Christophe Bornet

Not that it's preprogrammed with the workflow steps/navigation, but if it sees a "next" or "user-disable" link relation, it knows how to proceed/present that affordance to the user.

That's the semantic of the application that must be a shared understanding between the application and the user-agent. In HTML, that's generally human language. In OHM there are several possibilities : for humans (or any intelligent form), you can use the "summary" and "description" fields of the operations ; for computers (or anything with a limited vocabulary) you can use the "operationId" field of the operation. As said in the post, OHM doesn't define a vocabulary so you need to define your own or reuse an existing one.

is OHM meant for documentation or are you proposing it as an implementation hypermedia type?

It's an Hypermedia type. I thought it was clear in the title. Apparently not... 😅