A one-time action URL as a GET request does break the idempotency property, but what else are you going to do?
At the end of the day the pragmatic solution is best. Solve the problem while introducing as few side problems as possible. And keep it simple -- that's my general philosophy.
The real rabbit hole of the HTTP methods debate is once you get into the semantics of PUT/DELETE and frankly I don't see the advantage.
GET and POST have the simplest semantics and you can build APIs that are super clear, pragmatic and easy to use with just those two methods, occasionally bending the rules when it's helpful but keeping things as predictable as possible.
That article doesn't give a strong argument against ONLY using get/post IMO. His main point is to maintain idempotency, but you don't need all the extra verbs beyond get and post to do that.
"what else are you going to do"- The way to do it inline with HTTP standards is that the email link sends the user to a form where they click "confirm email" and that form sends a patch request. If you instead alter the resource in email GET link the action might be triggered without user interaction, "e.g. by a malware scanner, link previewer, or cache primer". To what degree this is actually an issue I'm not sure because many apis use GET regardless and it seems to work enough for them to continue doing it.
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.
A one-time action URL as a
GETrequest does break the idempotency property, but what else are you going to do?At the end of the day the pragmatic solution is best. Solve the problem while introducing as few side problems as possible. And keep it simple -- that's my general philosophy.
The real rabbit hole of the HTTP methods debate is once you get into the semantics of
PUT/DELETEand frankly I don't see the advantage.GETandPOSThave the simplest semantics and you can build APIs that are super clear, pragmatic and easy to use with just those two methods, occasionally bending the rules when it's helpful but keeping things as predictable as possible.Why you should use standard HTTP methods when designing REST APIs
Suhas Chatekar ・ Feb 23 '17 ・ 7 min read
That article doesn't give a strong argument against ONLY using get/post IMO. His main point is to maintain idempotency, but you don't need all the extra verbs beyond get and post to do that.
"what else are you going to do"- The way to do it inline with HTTP standards is that the email link sends the user to a form where they click "confirm email" and that form sends a patch request. If you instead alter the resource in email GET link the action might be triggered without user interaction, "e.g. by a malware scanner, link previewer, or cache primer". To what degree this is actually an issue I'm not sure because many apis use GET regardless and it seems to work enough for them to continue doing it.