Get VS. Post Best Practices

GET vs. POST Best Practices

In general it's not a good idea to have a GET request that modifies the system state somehow, like deleting an item.

You could have your form look like this:

<form action='item.php' method='POST' id='form'>
    <input type='hidden' name='action' value='delete' />
    <input type='hidden' name='id' value='{item_id}' />
    <a href="" onclick="document.getElementById('form').submit(); return false;">Delete item</a>
</form>

When should I use GET or POST method? What's the difference between them?

It's not a matter of security. The HTTP protocol defines GET-type requests as being idempotent, while POSTs may have side effects. In plain English, that means that GET is used for viewing something, without changing it, while POST is used for changing something. For example, a search page should use GET, while a form that changes your password should use POST.

Also, note that PHP confuses the concepts a bit. A POST request gets input from the query string and through the request body. A GET request just gets input from the query string. So a POST request is a superset of a GET request; you can use $_GET in a POST request, and it may even make sense to have parameters with the same name in $_POST and $_GET that mean different things.

For example, let's say you have a form for editing an article. The article-id may be in the query string (and, so, available through $_GET['id']), but let's say that you want to change the article-id. The new id may then be present in the request body ($_POST['id']). OK, perhaps that's not the best example, but I hope it illustrates the difference between the two.

What is the difference between POST and PUT in HTTP?

Overall:

Both PUT and POST can be used for creating.

You have to ask, "what are you performing the action upon?", to distinguish what you should be using. Let's assume you're designing an API for asking questions. If you want to use POST, then you would do that to a list of questions. If you want to use PUT, then you would do that to a particular question.

Great, both can be used, so which one should I use in my RESTful design:

You do not need to support both PUT and POST.

Which you use is up to you. But just remember to use the right one depending on what object you are referencing in the request.

Some considerations:

Do you name the URL objects you create explicitly, or let the server decide? If you name them then use PUT. If you let the server decide then use POST.
PUT is defined to assume idempotency, so if you PUT an object twice, it should have no additional effect. This is a nice property, so I would use PUT when possible. Just make sure that the PUT-idempotency actually is implemented correctly in the server.
You can update or create a resource with PUT with the same object URL
With POST you can have 2 requests coming in at the same time making modifications to a URL, and they may update different parts of the object.

An example:

I wrote the following as part of another answer on SO regarding this:

POST:
Used to modify and update a resource
POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/
Note that the following is an error:
POST /questions/<new_question> HTTP/1.1
Host: www.example.com/
If the URL is not yet created, you
should not be using POST to create it
while specifying the name. This should
result in a 'resource not found' error
because <new_question> does not exist
yet. You should PUT the <new_question>
resource on the server first.
You could though do something like
this to create a resources using POST:
POST /questions HTTP/1.1
Host: www.example.com/
Note that in this case the resource
name is not specified, the new objects
URL path would be returned to you.
PUT:
Used to create a resource, or
overwrite it. While you specify the
resources new URL.
For a new resource:
PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/
To overwrite an existing resource:
PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

Additionally, and a bit more concisely, RFC 7231 Section 4.3.4 PUT states (emphasis added),

4.3.4. PUT
The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload.

GET vs POST where to use which method

There is a formal definition of what the methods should be doing on the server side: https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Because of that formal definition, any ideal answer inevitably ends up sounding like a CRUD answer. GET should never modify data, it should only retrieve data. POST is intended to change data on the server.

In practice, we often find ourselves using POST as a work around for the fact that GET is effectively limited from having a content body in the request. Many data retrieval scenarios may need to send a content body to the server. You may also run into URL length issues in some GET scenarios that may cause you to send data in POST. So, if you're trying to retrieve data, prefer GET and use POST where you need to.

While I may use POST to work around limitations of GET for data retrieval, I would never use GET to modify data.

When do you use POST and when do you use GET?

Use POST for destructive actions such as creation (I'm aware of the irony), editing, and deletion, because you can't hit a POST action in the address bar of your browser. Use GET when it's safe to allow a person to call an action. So a URL like:

http://myblog.org/admin/posts/delete/357

Should bring you to a confirmation page, rather than simply deleting the item. It's far easier to avoid accidents this way.

POST is also more secure than GET, because you aren't sticking information into a URL. And so using GET as the method for an HTML form that collects a password or other sensitive information is not the best idea.

One final note: POST can transmit a larger amount of information than GET. 'POST' has no size restrictions for transmitted data, whilst 'GET' is limited to 2048 characters.

GET request with body VS POST for retrieving a large resource

"HTTP best practices" and "RESTFUL practices" are the same in this context: using the GET method token with a request body is bad practice.

use POST only when we want to make a change on the resources

That's not quite right - see it is okay to use POST (Fielding, 2009). Roughly summarized, POST is the HTTP method with the fewest constraints. We can always use it, but we should prefer to use a more specific method when the semantics of the request fits within the constraints.

For fetching a representation of a resource, we prefer to use GET, because that best communicates the semantics of the request to general purpose HTTP components, so that they can correctly interpret the semantics of the request and do useful things.

But that depends on being able to completely identify the resource using the information in the request line. If your identifier is too long, then that won't work, and you'll need to fall back to using POST, copying the "identifier" into the body of the request.

That "works", but the trade off is that general purpose components aren't going to know that the GET constraints still apply, and therefore aren't going to be able to anything intelligent (automatically retrying if a response is lost, caching results, and so on).

In late 2020, the HTTP-WG adopted a proposal to create a standard for a new method token, that would act as a "GET with a body". So at some point, we should start to see a registered standard, and conforming implementations, and so on.

RESTful API urls best practice GET vs POST

Your url should show what you want. Right now, you are requesting product; therefore, width and height are not meaningful.

mysuperstore.com/api/categories/40/products/53?width=100&height=100

I want product image in below url; therefore, width and height are more meaningful.

mysuperstore.com/api/categories/40/products/53/image?width=100&height=100

I normally want my services to be lean; thus, I would design my services like below. All selects will use GET method and other services will use other HTTP methods.

Most used product information
mysuperstore.com/api/categories/40/products/53
Product Image is in a different method; since, image size will be large compared to product information, and some clients may not need it.
mysuperstore.com/api/categories/40/products/53/image?width=100&height=100
Other details or extra information
mysuperstore.com/api/categories/40/products/53/details
Of course, a service my incorporate all information.
mysuperstore.com/api/categories/40/products/53/all
As you said in your question, POST/PUT/DELETE methods will be reserved for updating product information.

With this design, my clients will have a choice. Most of the time, normal product service and product image service will be used. Least used information will not travel in the network.

Is either GET or POST more secure than the other?

As far as security, they are inherently the same. While it is true that POST doesn't expose information via the URL, it exposes just as much information as a GET in the actual network communication between the client and server. If you need to pass information that is sensitive, your first line of defense would be to pass it using Secure HTTP.

GET or query string posts are really good for information required for either bookmarking a particular item, or for assisting in search engine optimization and indexing items.

POST is good for standard forms used to submit one time data. I wouldn't use GET for posting actual forms, unless maybe in a search form where you want to allow the user to save the query in a bookmark, or something along those lines.

Get VS. Post Best Practices