I feel like the "DEL | PUT | PATCH" verb are overrated. I still cannot see it's usefulness to this day.

so what do you do when you want to delete something? `POST itemurl/delete`? or `GET itemurl?action=delete`?

@tosensei I prefer to do…

POST => items/delete/{id}

POST => items/create

POST => items/update

GET => items/{id}

@GiddyNaya it works, but it doesn't follow the REST principles (just to say, there is a verb in the path)

It's good for tagging. There's a lot of software that visualizes network communication, and if everything is POST then everything is the same color. You want more verbd simply to keep shit organized... In the same way you don't really need classes, packages or even folders, everything can be one long file... But man, that would be a hassle

Also @GiddyNaya
By your Standard, in your example, your GET should be

GET /items/get/{id}

Otherwise you're mixing explicit path naming with requests typing. You should Stick to one if that's the case

Well put lol… I kinda feel like an amateur in the REST thingy.

I like HTTP verbs for REST because they're simple. Why overengineer something with too many layers when the simple solution works just fine?

Over engineering only leads to unfortunate "status 200 {error: "bla bla failed"}" situations

GET — request data
POST — transfer data and make something happen
PUT — upload file or other large payload
PATCH — change data on server
DELETE — delete data/record on server

They all have their uses!

@GiddyNaya sorry, but what you prefer to do is ugly and disgusting.

@Root I always saw patch as a partial update and put as an overwrite/full update

HTTP verbs and HTTP response codes are implemented for a reason. Use them.

I think one might wanna take a closer look again on why this is important...

Yeah. It's me, the nitbit freak.

I really really really really really really really recommend to read the specs.

https://httpwg.org/specs/...

The reason: It explains very well the thought process behind http methods.

Method is the key word here - that interestingly noone has used yet.

The http standard has very clear rules about methods - non safe vs safe, idempotent and thus retry safe vs non safe.

This is missing in an path based API. Simply put, a path based API specification without using methods is non compliant - it's up to the API specification to clarify this.

Needless to say that many APIs using HTTP methods implemented it wrong - but there is a standard that can be pointed to and thus a reason to say: Guys fix this shit, it's fucked up.

The other thing that methods make imho unbeatable is ACL and security.

Filtering based on paths is ridiculously stupid. It's a game one cannot win. you end up with a myriad clusterfuck of expressions that you cannot validate.

Filtering on a method? Plain stupid simple. 501… get the fuck off my lawn.

Not using methods is really throwing away a lot of good and well intended concepts that were way ahead of it's time.

@GiddyNaya Are you a fan of dynamically typed languages? Because you have an URL segment of type: "usually ID except if it's equal to any of a couple magic strings" which is the lowest of shitty JS tricks in existence.

@TheCommoner282 Interesting!

Why wouldn’t POSTs also be idempotent, though?

@Root because every POST creates a _new_ entity.

They each have different guarantees.

PUT - has body, repeatable
DELETE - no body, repeatable
GET - no body, idempotent
POST, PATCH - has body, stateful

DELET and PUT must be sent at least as many times as they are issued. GET need not be sent more than once if the cache is valid. I'm not entirely sure why PATCH is distinct, it would make a lot of sense to categorize POST as an unspecified RPC which may or may not create something(s), modify something(s) or delete something(s). In reality that's how it's used almost everywhere anyways, and most modifications can be recognized as a combination of creations and deletions, so even conceptually PATCH doesn't make sense.