to quote original's author blog, strong typing of resources exposed by an api, doesn't make it less restful or less hateoas; so it's not in disagreement with level 3 as explained by m.f. > A REST API should never have typed resources that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client. The only types that are significant to a client are the current representations media type and standardized relation names. typically, I don't think a standard "CRUD" is a good example of what REST was coined for (I'm not saying it's bad; I'm saying it feels just against the entire initial idea of REST and HATEOAS) I don't think typing an api is a bad thing. I think that: - it's not required per se - if done, it should be done with forward/backward compatibility in mind - it's likely not a time saver to generate automatically - it doesn't prevent the api to be documented
> typically, I don't think a standard "CRUD" is a good example of what REST was coined for (I'm not saying it's bad; I'm saying it feels just against the entire initial idea of REST and HATEOAS) I agree with this 100 %, a CRUD API is definitely not what REST was coined for