.net webapi HttpGet vs HttpPost. why HttpGet?

Question

Why use HttpGet instead of HttpPost in the WebApi framework?

I understand well the difference between a Post or Get type, one is via url and the other not (as basic understanding)

But also I know the principal difference (which can be edit on the server) is that Post doesn't have any limitation in the data size send it to the server, while the GET type has a limitation of

(2000 characters (IE's limit.)) Is there a limit to the length of a GET request?

When I been coding large amount of data sometime I been frustrated to send data which is over the limit data size via GET and found the server sending error and erros and is because the size, so I have to change my methods in favor of POST type.

namespace somenamespace.Controllers
{
    public class someController : ApiController
    {
        [HttpPost] //<--- change all
        public somenamespace.Class getSomething(string key1, string key2) {
            return new someblabla.Models.Class.Class(key1,key2).getSomething();
        }
    }
}

So why would be a GOOD reason when someone want to use GET instead of POST, while POST is always working with any restriction at all.

I'm talking about only about WEB API .net. I know if you want to request variables and information via an url string (sending vía page to page) or something like that GET can be more easy to implement.

Answer 1

Ultimately you can always do whatever you want but it's good practice to follow some standards - not just for the standard's sake but to make your code predictable and easy to use.

When you call your API RESTful people will assume that, e.g.:

• any GET request will just get the data - not modify, not delete, not create

• any POST request will create a resource

• PUT requests will update resources, and you can execute them as many times as you want without side effects

• DELETE will, well, delete the resource

That makes everyone's life easier and is sort of a contract between you and your customers.

I highly recommend that you read this resource on RESTful design of APIs - you'll get the idea what reasons people have for following a convention:

http://info.apigee.com/Portals/62317/docs/web%20api.pdf