What is the difference between String and StringBuilder?

Both String and StringBuilder are classes used to handle strings.
The most common operation with a string is concatenation. This activity has to be performed very efficiently. When we use the "String" object to concatenate two strings, the first string is combined to the other string by creating a new copy in the memory as a string object, and then the old string is deleted. This process is a little long. Hence we say "Strings are immutable".
When we make use of the "StringBuilder" object, the Append method is used. This means, an insertion is done on the existing string. Operation on StringBuilder object is faster than String operations, as the copy is done to the same location. Usage of StringBuilder is more efficient in case large amounts of string manipulations have to be performed.

difference Methods GET and POST in HTML forms

The fundamental differences between "GET" and "POST"

The HTML specifications technically define the difference between "GET" and "POST" so that former means that form data is to be encoded (by a browser) into a URL while the latter means that the form data is to appear within a message body. But the specifications also give the usage recommendation that the "GET" method should be used when the form processing is "idempotent", and in those cases only. As a simplification, we might say that "GET" is basically for just getting (retrieving) data whereas "POST" may involve anything, like storing or updating data, or ordering a product, or sending E-mail.

Differences in server-side processing

In principle, processing of a submitted form data depends on whether it is sent with METHOD="GET" or METHOD="POST". Since the data is encoded in different ways, different decoding mechanisms are needed. Thus, generally speaking, changing the METHOD may necessitate a change in the script which processes the submission. For example, when using the CGI interface, the script receives the data in an environment variable when METHOD="GET" is used but in the standard input stream (stdin) when METHOD="POST" is used.

It is, however, possible to construct libraries of subroutines (e.g. Perl functions) which allow one to write scripts in a manner which works both for METHOD="GET" and METHOD="POST". This would be based on distinguishing between the cases within the subroutine code and returning the data to the caller in a uniform manner.

Possible reasons to use "POST" for idempotent queries

For reasons explained above, one should normally use METHOD="POST" if and only if the form submission may cause changes. There are some exceptional situations where one may consider using METHOD="POST" even for pure queries, too:

• If the form data would contain non-ASCII characters, then METHOD="GET" is inapplicable in principle, although it may work in practice (mainly for ISO Latin 1 characters). Thus, for a query where the keywords might contain e.g. accented letters, you have to select among two evils: using METHOD="GET" against the rules which restrict the character reportoire to ASCII within it, or using METHOD="POST" against the rules which says that it should not be used when the processing is idempotent. The latter alternative is probably less dangerous.
• If the form data set is large - say, hundreds of characters - then METHOD="GET" may cause practical problems with implementations which cannot handle that long URLs. Such usage is mentioned in the the HTML 2.0 specification in an informative note as follows:

  Note - The URL encoding may result in very long URIs, which cause some historical HTTP server implementations to exhibit defective behavior. As a result, some HTML forms are written using METHOD=POST even though the form submission has no side-effects.

• You might wish to avoid METHOD="GET" in order to make it less visible to users how the form works, especially in order to make "hidden" fields (INPUT TYPE="HIDDEN") more hidden. Using POST implies that users won't see the form data in the URL shown by the user; but note that this is not a very effective method of hiding, since the user can of course view the source code of your FORM element!