Simple explanation about SOAP and REST
SOAP - "Simple Object Access Protocol"
SOAP is a method of transferring messages, or small amounts of information, over the Internet. SOAP messages are formatted in XML and are typically sent using HTTP (hypertext transfer protocol).
Rest - Representational state transfer
Rest is a simple way of sending and receiving data between client and server and it doesn't have very many standards defined. You can send and receive data as JSON, XML or even plain text. It's light weighted compared to SOAP.
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.
Best Answer
Although REST is stateless, it has state transfer in its name. It's a little bit confusing to everyone.
Stateless
When you open a web page in the browser, you will act as a service consumer and the www server will act as a service provider to serve you with a webpage. If it is a normal connection, the client and the server will both perform a handshake and initiate a session (called a TCP connection).
After that, based on the server's and client's behavior, the state will change to either ESTABLISHED, IDLE, TIMEOUT, etc. But in REST, we are using the HTTP protocol which is a stateless, meaning the server will not store any session information about the client. The client is responsible for sending all of the details required by the server to get serviced, meaning when we invoke the URI
http://somedomain:8080/senthil/services/page1from the server, it has enough details about the client to serve page1 fully.State Transfer
Using the same example, when you open a web page using some URL to view an image file (RESOURCE) on the server,the www server will show you (the client) the image in some format i.e a REPRESENTATION of the RESOURCE (image file).
During this process, the constant resource state of the server (i.e. the state of the image file which is stored in the server database) will be represented to client in an understandable format i.e. application state of the client. So, the resource state will remain constant in respect to clients, and only the representation of the resource will change, which in turn would change the application state.
Finally, the representation of the resource (how the image is displayed to the client), which implicitly changes the state of both the server and the client is called REST.