3 ms·
I didn't say they needed to use REST. REST is a huge mess. You can simplify it to GET = doesn't change stuff, POST = changes stuff. Basic HTML form tag stuff.
by kayodelycaon 3y ago
I didn't say they needed to use REST. REST is a huge mess.
You can simplify it to GET = doesn't change stuff, POST = changes stuff. Basic HTML form tag stuff.
For the few things in-between like self-expiring links or counters recording how many times a thing was viewed can get tossed into GET because the data you're retrieving isn't being modified. (Search can be POST if you don't like query parameters in your urls.)
- User23 3y agoGET: get a thing from a place. PUT: put a thing in a place. POST: create a new place, put a thing there, and tell me its location. DELETE: delete the contents of an existing place. The biggest subtlety I can think of is deciding whether PUT to a place that doesn't exist is valid, and whether DELETE of a place should delete just the object or also the place too, if PUT is only valid for existing places. How to handle that subtlety is application dependent. Personally I like to architect RESTful services such that POST isn't necessary since it's hard to make it idempotent, but sometimes POST is the most comprehensible interface. Also, I wouldn't bother using REST at all unless I was going to make everything fully discoverable via hypertext[1]. However that's not to say there aren't soundly designed non-RESTful ways to use the HTTP application protocol. [1] https://en.wikipedia.org/wiki/HATEOAS https://en.wikipedia.org/wiki/HATEOAS