3 ms·

I was definitely in the wrong about GET/POST. The company I had previously worked for simply didn't really care too much about getting the verbs right, so I did

by johnfn 6y ago

I was definitely in the wrong about GET/POST. The company I had previously worked for simply didn't really care too much about getting the verbs right, so I didn't really fret about them. And the company I'm currently at (multiple thousands of employees, strong engineering culture if I dare say so myself) just does everything as a POST. So it really is somewhat cultural whether you care about GET/POST or not. But, IMO, even if you don't know, it's the kind of thing you learn once in code review and then don't worry about again.

cameronh90 6y ago
For E2E encrypted APIs, one could well argue that worrying about HTTP verbs is just wasting time for no good reason. POST (consistently) lets you attach a body too. Just using POST for everything is a pattern I've seen becoming more popular recently.
- deleted 6y ago
  [deleted]
- chrisandchris 6y ago
  No we can get into an endless argument whether verbs are abused or not... IMHO, GET (as of today) gas the issue that it does not support a body. If I‘m executing a search (an idempodent action), how can I nicely pass a JSON object configuring the search? I‘ll just use POST for that... So then we‘re at the point where the url does not work anymore because we have a POST /findEmployee; POST /findContract; ... instead of GET /employee and GET /contract. Maybe I‘m wrong here, but it doesn‘t like nice in my eyes using POST in that way.
  - ulucs 6y ago
    The JS API's I used to develop in used a mix of query strings (for exact matches) mixed with JSON (for more complicated queries) all in the url parameters
andreareina 6y ago
Google Places API puts the key in a query parameter. Still don't know how I feel about that.