This is bad advice. The HTTP method is a contract. If you break that contract, you run the risk of your API not working with intermediate services like an HTTP cache layer.

It's not a good idea to implement your own security code especially if you aren't a security expert. I assume that the concern with using a third party solution is cost? If so, I suggest keycloak.org. It's free and open source and easy to use.

@wired_in REST in Practice is my favorite book on REST :-), but it's been a few years since I've re-read it. As influential as it was, my experience and research on hypermedia systems have also influenced my understanding of these concepts. No, URLs are not defined to be unique, but they are effectively unique because generic components don't know your domain's semantics and thus can only treat them as unique. You'll avoid a lot of problems with intermediaries like caches if you think of them as unique. Consider it a rule of thumb if not a rule.

@wired_in In your example of filtering a list using query params, the resource is the list, not the items in the list. If you change the filter, you get a different list. REST has no concept of a list of resources, or sub-resources, or child-resources. That's semantics that we add, but the system doesn't know. Again, think of an HTTP Cache layer. The cache doesn't know that it has a list of resources. It doesn't even know that what it has represents a list. Working with caches has driven this concept home for me.

@wired_in As for query params, RFC 3986 states "The query component contains non-hierarchical data that, along with data in the path component, serves to identify a resource". It's just an alternate pattern for identifying a resource. Any semantics that your server gives to any part of the URL is irrelevant to the system as a whole. If it's not identified by the same string of characters, the system will treat it like a different thing.

@wired_in URI stands for Uniform Resource Identifier. It's whole reason for being is to identify resources. Although it's possible to write a server that treats two URLs are the same resource, it's effectively two separate resources to the system. Consider an HTTP caching layer. It can't give you a cached version of /orders when you request /clients/{id}/orders. It doesn't know that you intended those to be the same resource. That's why there are multiple mechanisms to indicate that URL is not the canonical URL for the resource including status codes, headers, and link relations.

That was my first thought too when I read the question, until I realized he was talking about modifying the fields he was returning using query params. But, I should have mentioned it anyway. Glad you did +1

These are architectural level concerns, so it applies the same to any programming language. I suggest you start with choosing a media type (JSON Hyper-Schema, Siren, etc). Then find (or build) a user-agent for that media type. Then build your server such that you can navigate your application using that user-agent. That experience of building your server to work with a general purpose user-agent will be better than any reading material I could give you.