Implicit or somewhat implicit rules are really what governs a REST API. For example, we simply must know a
GET request to the root resources fetches all entries of that resource. A
POST request to the same endpoint will, on the other hand, create an entity or resource.
Interesting article, with a lot to agree and disagree on. However... you're not talking about REST it seems. Take this nice little quote above and putit next to what Fielding wrote about that 12 years ago (https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post):
"Some people think that REST suggests not to use POST for updates. Search my dissertation and you won’t find any mention of CRUD or POST. The only mention of PUT is in regard to HTTP’s lack of write-back caching. The main reason for my lack of specificity is because the methods defined by HTTP are part of the Web’s architecture definition, not the REST architectural style. Specific method definitions (aside from the retrieval:resource duality of GET) simply don’t matter to the REST architectural style, so it is difficult to have a style discussion about them. The only thing REST requires of methods is that they be uniformly defined for all resources (i.e., so that intermediaries don’t have to know the resource type in order to understand the meaning of the request). As long as the method is being used according to its own definition, REST doesn’t have much to say about it."
And while you're at it, have a look at this as well: https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
REST is intended for hypertext/hypermedia systems, not for generic APIs. With that in mind, it seems you were on the wrong path from the start for most of your applications....