1 min readMay 16, 2018
- Why would we use 2 different conventions where simple request endpoint contains params in URL (company/2/employe/3) and sorting/filtering/etc. requests use queries (company?id=2&employe=2)? This is very confusing. Why don’t we always use queries, since we never know what additional param we might need in future? Basically, every request to API is a “filtering” request, because we always pass params so API could find what we need and do what we want it to do.
- “We need to append the query params with the GET method API” — never understood this one. By nature, GET requests are the worst (limits, security, etc). It means, for me at least, that there has to be a very good reason to use it. Eventually, all we need is to call our API and say what we want it to do. If we have a clear set of rules in place and flexible framework it doesn’t matter how we make requests (GET/POST/PUT/DEL or just POST).
- Versioning is always a huge pain. From my own experience, while it depends on API’s nature, it’s better to think of methods/controllers versioning and pass “version” via headers and use semantic versioning (major.minor.patch) instead of pointing to a new endpoint with a single digit version like v2. This way it’s also easier to manage releases.
