What about adding a field, removing a field or updating the type of data stored on a field? HATEOAS doesn't offer anything for that. This is why I feel we need more experimentation, more standardization, more time before some practices stand out enough to consider them 'best practices'
Isn't HATEOAS more about just URL changes, though? It is about letting the responses provide available responses to the client. This requires a commitment to creating media types or using existing ones, along with using link relations. Not using REST correctly leads to such complicated best practices that recommend adding .json to a URL to get the JSON representation. You shouldn't have to go to the documentation to figure out have to craft that URL to get a representation of a resource.
Than maybe it's too soon to have any kind of best practices. We agree that more experimentation is needed, but when is that going to happen when everyone is building according to the REST-but-not-really best practices and the systems trying new things are toy services?
Mutations in the resource are addressed by changes in the media type. You're talking about it as if it was rocket science, while everything is very well addressed.
Those tags only address mutations to a URL.
What about adding a field, removing a field or updating the type of data stored on a field? HATEOAS doesn't offer anything for that. This is why I feel we need more experimentation, more standardization, more time before some practices stand out enough to consider them 'best practices'