2 replaced http://stackoverflow.com/ with https://stackoverflow.com/
source | link

So, when a GET request is sent over HTTPS, its query parameters are secure in transit. However, it can more easily leak data at the endpoints (browser history, referrer URLs, and server logs notably) than POST can. See this answerthis answer and this old blog post.

Aside from referrer leakage, I'm usually not too concerned about using GETs. GET URLs are nice precisely because you can bookmark and share queries that you commonly run. Often, if I'm deciding between POST and GET for queries, it more comes down to these factors:

Can the search parameters fit in a URL query string?

Some browsers will truncate URLs past a certain sizecertain size.

If you have a complex object representing your request, then it can be difficult to convertdifficult to convert to/from a URL query string automatically.

Is my request object useful as part the URL?

Even if you can convert/fit an object into a query string representation, that doesn't mean it will be useful to do so. If you have too many properties, it is still tedious to construct query strings in the browser.

In contrast, using POST you can include your complex or large request object as JSON or whatever format you fancy. If you want to log it, you still can through your application.


I often use GETs for full text type searches:

GET /customer?skip=0&take=50&search=my+search+text

But for more complex scenarios, I might use POST based on the guiding factors above.

If you look at most search engines, they use GET with query parameters. It's the best fit for what they do. For the analytics services POST-based makes sense, because it offers a lot more fine-grained control over your requests via more complex request objects.

So, when a GET request is sent over HTTPS, its query parameters are secure in transit. However, it can more easily leak data at the endpoints (browser history, referrer URLs, and server logs notably) than POST can. See this answer and this old blog post.

Aside from referrer leakage, I'm usually not too concerned about using GETs. GET URLs are nice precisely because you can bookmark and share queries that you commonly run. Often, if I'm deciding between POST and GET for queries, it more comes down to these factors:

Can the search parameters fit in a URL query string?

Some browsers will truncate URLs past a certain size.

If you have a complex object representing your request, then it can be difficult to convert to/from a URL query string automatically.

Is my request object useful as part the URL?

Even if you can convert/fit an object into a query string representation, that doesn't mean it will be useful to do so. If you have too many properties, it is still tedious to construct query strings in the browser.

In contrast, using POST you can include your complex or large request object as JSON or whatever format you fancy. If you want to log it, you still can through your application.


I often use GETs for full text type searches:

GET /customer?skip=0&take=50&search=my+search+text

But for more complex scenarios, I might use POST based on the guiding factors above.

If you look at most search engines, they use GET with query parameters. It's the best fit for what they do. For the analytics services POST-based makes sense, because it offers a lot more fine-grained control over your requests via more complex request objects.

So, when a GET request is sent over HTTPS, its query parameters are secure in transit. However, it can more easily leak data at the endpoints (browser history, referrer URLs, and server logs notably) than POST can. See this answer and this old blog post.

Aside from referrer leakage, I'm usually not too concerned about using GETs. GET URLs are nice precisely because you can bookmark and share queries that you commonly run. Often, if I'm deciding between POST and GET for queries, it more comes down to these factors:

Can the search parameters fit in a URL query string?

Some browsers will truncate URLs past a certain size.

If you have a complex object representing your request, then it can be difficult to convert to/from a URL query string automatically.

Is my request object useful as part the URL?

Even if you can convert/fit an object into a query string representation, that doesn't mean it will be useful to do so. If you have too many properties, it is still tedious to construct query strings in the browser.

In contrast, using POST you can include your complex or large request object as JSON or whatever format you fancy. If you want to log it, you still can through your application.


I often use GETs for full text type searches:

GET /customer?skip=0&take=50&search=my+search+text

But for more complex scenarios, I might use POST based on the guiding factors above.

If you look at most search engines, they use GET with query parameters. It's the best fit for what they do. For the analytics services POST-based makes sense, because it offers a lot more fine-grained control over your requests via more complex request objects.

1
source | link

So, when a GET request is sent over HTTPS, its query parameters are secure in transit. However, it can more easily leak data at the endpoints (browser history, referrer URLs, and server logs notably) than POST can. See this answer and this old blog post.

Aside from referrer leakage, I'm usually not too concerned about using GETs. GET URLs are nice precisely because you can bookmark and share queries that you commonly run. Often, if I'm deciding between POST and GET for queries, it more comes down to these factors:

Can the search parameters fit in a URL query string?

Some browsers will truncate URLs past a certain size.

If you have a complex object representing your request, then it can be difficult to convert to/from a URL query string automatically.

Is my request object useful as part the URL?

Even if you can convert/fit an object into a query string representation, that doesn't mean it will be useful to do so. If you have too many properties, it is still tedious to construct query strings in the browser.

In contrast, using POST you can include your complex or large request object as JSON or whatever format you fancy. If you want to log it, you still can through your application.


I often use GETs for full text type searches:

GET /customer?skip=0&take=50&search=my+search+text

But for more complex scenarios, I might use POST based on the guiding factors above.

If you look at most search engines, they use GET with query parameters. It's the best fit for what they do. For the analytics services POST-based makes sense, because it offers a lot more fine-grained control over your requests via more complex request objects.