HTTP Methods - what about only using POST for Ajax calls?

Question

You can find whole articles theorizing when you should use what METHOD in what edge case.

It mostly comes down to this; every action needs to be simplified to in just four flavours (GET, POST, PUT, DELETE) - and this is often insufficient to be expressive.

Especially if you look at domain driven design, this is unfit. I would argue that every developer that tries to shoehorn all his code into just these methods (in their Java code) will have some bad time during code reviews. You clearly need to have documentation to be really sure what is going on.

/employees/active/john-doe (DELETE)

Does DELETE mean DELETING the resource, or DELETE (remove) it from the 'active' list?

/employees/active/john-doe/remove-from-active

would be a lot more expressive. Everyone using this method will be confident that we are not accidently deleting this employee. POST, GET, who cares - as long as we are authorized.

Some people will probably theorize that the first url is anyway not expressive - but then what would the DELETE method really add? If the URL on itself is expressive - isn't the DELETE method duplicate information (not DRY)?

Is there anything wrong with being pragmatic and always use POST?

For some time I'm actually just using POST methods for all my Ajax calls. Except some caching issues I don't see any problems.

While I would be in favour of dropping Method at all, I think there is actually a more clear distinction between GET and POST, because GET expresses no side effects.

Am I missing something or are we (as internet community) embracing legacy design just because it is already there and we are stuck with it? Are there any good arguments that Http Method is a 'good design', besides that we should stick to conventions that are already there?

Answer 1

The arguments to use GET, POST, PUT and DELETE methods for HTTP calls usually revolve around RESTful web services. REST (Representational State Transfer) is just an attempt at leveraging the existing HTTP protocol for something more than "SUCCESS!" or "FAIL!" type of messages.

If you aren't adhering to the guidelines of REST, then there is nothing wrong with choosing GET or POST requests.

(In gruff, old-man voice) back in the day it was "best practice" for all AJAX calls to be POST requests so somebody couldn't launch an attack on your site by placing a little JavaScript tag on a hacker's website:

<script type="text/javascript" src="https://www.yourcompany.com/ajax?foo=bar"></script>

And then duping your (hopefully logged-in) users to visiting the site.

The browser still makes the HTTP GET request. It still sends the cookies to the server telling your app that they are logged in. Sure the browser can't execute the result, but the request was made and processed.

If your AJAX endpoint responds to POST or PUT requests it is much harder to do this sort of attack (end gruff old-man voice).

Answer 2

Is there anything wrong with being pragmatic and always use POST?

No, It's great.

are we (as internet community) embracing legacy design just because it is already there and we are stuck with it?

Jeeze I must be getting old if REST is legacy now.

People argue about RESTfullness because its a set of rules you can argue about.

People like rest because it's easy compared to SOAP and the like. esp. for web developers who are already using HTTP all over the place.

There are some clear technical flaws/questions with trying to shoehorn things into the HTTP Methods

• Length of URL restriction on GET
• Can Get have a body
• Should an API server have the same caching rules as a web server?
• Sending lists of things in an URL
• What does code 202 really mean?
• Should the web server log the request URL

etc.

At the end of the day the REST 'spec' isn't rigorous enough to tell you what Method to use, even if you do wan't to follow it