GET is just a method. How it is implemented on the server is up to the server.
You could run all your API on GET and act upon either the URL components or the body of the GET (there should be none, but you can use one).
GET /list → lists your objects GET /name/add/john → adds the name "john" GET /name/delete/john → deletes "john"
Sure, the nice way is to use PUT, DELETE etc. but the above can work perfectly. This is actually used by some APIs.
Of course, according to the specification, GET is expected to be idempotent but, again, this is just an expectation, the server can do whatever pleases it.
Right, I misunderstood you, thanks for clarifying your point!
The article assumes a correct implementation of GET which follows from the specification. I will add an edit to state that explicitly.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very nice article.
GET is idempotent only if the server says so. There is nothing in the protocol itself they would enforce it.
Thank you!!
I have to disagree, however. I believe that, according to datatracker.ietf.org/doc/html/rfc7..., GET is in fact both a safe and idempotent method!
GETis just a method. How it is implemented on the server is up to the server.You could run all your API on
GETand act upon either the URL components or the body of theGET(there should be none, but you can use one).GET /list→ lists your objectsGET /name/add/john→ adds the name "john"GET /name/delete/john→ deletes "john"Sure, the nice way is to use
PUT,DELETEetc. but the above can work perfectly. This is actually used by some APIs.Of course, according to the specification,
GETis expected to be idempotent but, again, this is just an expectation, the server can do whatever pleases it.Right, I misunderstood you, thanks for clarifying your point!
The article assumes a correct implementation of
GETwhich follows from the specification. I will add an edit to state that explicitly.