Each HTTP method has its own regulations. For example, making an HTTP GET request requires two pieces of information – the method and the target URL, and an optional third the query string.
HTTP GET:
A GET goes out the internet and reads something and returns that information back to your IBM i System.
You would never use GET to create or modify a resource. For this you would use a PUT or a POST.
Let's look at both:
An HTTP PUT is supposed to accept the body of the request, and then store that at the resource identified by the URI.
An HTTP POST is more general. It is supposed to initiate an action on the server. That action could be to store the request body at the resource identified by the URI, or it could be a different URI, or it could be a different action.
PUT is like a file upload. A put to a URI affects exactly that URI. A POST to a URI could have any effect at all.
HTTP PUT:
PUT puts a file or resource at a specific URI, and exactly at that URI. If there’s already a file or resource at that URI, PUT replaces that file or resource. If there is no file or resource there, PUT creates one. PUT is idempotent, but paradoxically PUT responses are not cacheable.
HTTP POST:
POST sends data to a specific URI and expects the resource at that URI to handle the request. The web server at this point can determine what to do with the data in the context of the specified resource. The POST method is not idempotent, however POST responses are cacheable so long as the server sets the appropriate Cache-Control and Expires headers.
One benefit of REST vs SOAP is that when using HTTP REST , it encourages the proper usage of the HTTP verbs/methods. So for example you would only use PUT when you want to create a resource at that exact location.
As an RPG Programmer I think of GET as a READ, POST as a WRITE and a PUT as an UPDATE