The discussion related to Servlets are done here..
Idempotent Vs Non-idempotent requests
Wikipedia says, Idempotence IPA: describes the property of operations in mathematics and computer science that yield the same result after the operation is applied multiple times
From my understanding:
Idempotent: Even after making a repeated requests, the state of the object at the server should NOT change!
Non-Idempotent: As there are possible chances that the state of the object (data) get modified/updated, it is non idempotent. Opposite that of idempotent.
From JavaRanch Threads:
From the thread -> http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=18&t=012789
- Reply from Gian Franco:
A request is idempotent if a subsequent identical request can be performed and has equivalent results, in other words the side-effects of all subsequent identical requests is the same as for a the very first request
- Reply from Deepak Jain:
Idempotent: Multiple request to a servlet with same parameters must not have side effects on server.
Is it good to be idempotent: Yes.
GET: HTTP SPEC says that GET is idempotent. GET must be used to GET things from the server. Although it can be used to update data on the server. Ideally it should be used to get things from the server. Since this is what GET is supposed to be used GET SAME THINGS again and again from server will never cause any side effects on the server. And hence GET is considered to be idempotent.
POST: HTTP SPEC says that POST is not idempotent. POST must be used when you want to update the server and hence it can become non-idempotent that is multple same requests can cause side effects on the server.
From the thread -> http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=7&t=019565
- Reply from sunny dhoni:
GET - idempotent or safe (no side effects on server)
as it requests to return the content on the server and not modify it
POST - not impotent or unsafe (side effects on server)
as it might modify the contents on the server
HEAD - idempotent or safe (no side effects on server)
as it will just ask for header part and not the content in the response (response similar to GET except the body)
PUT - not impotent or unsafe (side effects on server)
ask the server to put or modify data on server at particular uri
DELETE - not impotent or unsafe (side effects on server)
delete the resource on server
OPTIONS - idempotent or safe (no side effects on server)
asks for options available on server like content-length
TRACE - idempotent or safe (no side effects on server)
ask to return traceback of the request
CONNECT - idempotent or safe (no side effects on server)
just ask to connect to the server with host and port args
for more info go to Protocols
- Excellent reply from Stan James - Bartender:
And it's not really about never making updates, but about making the same update every time. If a PUT sets shoe size to 8 every time you call it, it can still be idempotent. If it increments a counter every time, it isn't.
From W3C Protocols:
9.1.2 Idempotent Methods
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.
However, it is possible that a sequence of several requests is non- idempotent, even if all of the methods executed in that sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence.
A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed on the same set of resources).
All this tells how HTTP protocols "should" work. There's nothing but convention to prevent the code we add to an application server from breaking all the rules.
One time we care about this is when working with unreliable messaging. Maybe we send an update and never get a confirmation reply, so we send another copy of the same update. If it's idempotent, the second update will do no harm.
- Reply from Ulf Dittmer - bartender:
On quoting the POST and DELETE aspects of sunny dhony,
To expand on what Stan said, not only should PUT and DELETE be implemented in an idempotent manner, but being safe and being idempotent are not the same concept.
- dfd
RequestDispatcher from "request" Vs "ServletContext"
The RequestDispatcher can be obtained from both the Request object and ServletContext object. What is the difference between these two?
The reference URL is : http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=18&t=012664
The Answer from Marc Peabody is :
Every client request is submitted with a URL. So every request object on the server is tied to some URL.
ServletContext, on the other hand, is basically the web application itself. It was not created because of any URL. It is created when the container is started.
So if a request object was the result of a URL of "http://javaranch.com/someWebApp/folder/directories/finance" and you ask the request for a RequestDispatcher with "result.jsp", it will say "Hmmm, no leading slash means it wants me to make a new URL relative to my own. That means it wants http://javaranch.com/someWebApp/folder/directories/result.jsp! Piece of cake!"
But if you try the same thing to the ServletContext, it says "Are you kidding me!?! I've got like 100 places to look for this dumb file - and if I find two or more by the name result.jsp I have no clue which one you really want! Just give me the full directory structure *starting with a leading slash* from my root and I'll help you out. Throw me a freakin' bone here!"
doGet Vs doPost()
Reference thread in javaranch: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=7&t=020308&p=1
Traditionally there where distinct uses for GET, POST and other HTTP message types, but over time many have fallen into rare usage and GET and POST have often been treated as interchangeable.
Going back to their original intents, GET was designed to be used for 'repeatable' requests, commonly called 'idempotent'. If you browse a catalogue, all 'browse' operations would be expected to be repeatable.
POST operations would involve state changes and not designed for repeating. Logging in, purchasing, registering etc would be POST operations.
While both involve sending and receiving data over HTTP, there are subtle differences that can encourage the choice between ond message type and another.
Links
- Servlets and JSP best practices
- Evil InvokerServlet and should better be disabled -> http://faq.javaranch.com/diff?InvokerServlet
- gfjgf
