Skip to main content

HTTP Requests and Responses


Requests:

There are two types of requests:

  • Idempotent
  • Non-Idempotent

Idempotent:

The requests which produce same effect (do not affect the data) on repeated requests, are idempotent.

In other words, Same request can be made twice with no negative consequences to the server.

  • GET
  • DELETE
  • PUT 
These are idempotent, because once deleted or updated or read, they do not change anything on the server.

Non-Idempotent:
The request whose changes produces different effect every time,  is non-idempotent. This means every time we send request to the server; the database of server is updated on each request.
  • Post
  • Patch
These are idempotent and needs to be managed carefully to check whether this request is previously fulfilled or not. 
For Example: If we place an order using our bank account details, order would be placed. If the order is placed again at the same type (because we didn't get any response back, we place the same order again, then it would again place that order, so we need to handle this situation).

Functions:

Now there are some important request functions:
  • getHeader(String);
  • getIntHeader(String); //If you are sure that the content is integer, to avoid the extra step of parsing, we directly get the value of that key in integer.

Response:

Content Type:

In response, first of all we get response object and set content type, so that browser gets to now which application or assistant it has to call
  • text/html             (html reader)
  • application/java    (java renderer)
  • application/JAR    (JAR reader)
that's why we specify content type so that we can help the browser and save extra work and energy of identification of format.

Headers:

Now we come to the part of set Headers:

There are quite a few functions of setHeaders:
  • setHeader("key", "value");   //overwrites the value if already some value is present
  • addHeader("key","value");  //add more attributes
now the difference is that setHeader() allows only one value for one key:

For Example:
If we say response.setHeader("content-type", "text/html"); we all know there can only one content type, either it is a text or application or a media, so we we use addHeader("content-type", "text/html"); and then again we use addHeader("content-type", "application/jar");, then our content type attribute will have two values:
  • text/html 
  • application/jar

and then web browser would get super confused and throw an error, so to avoid this problem, we use setHeader(); and both of them serve their own purposes.




Comments

Popular posts from this blog

Java Servlets

  According to me its just a translator, who manages the HTTP requests and handle them to the appropriate function of the API. So then, API turns out to be a term or set of those functions which are kept public. Now let us see in little bit of detail what servlets are: For that we need to see few terms: Static Web Pages: Static web pages are the pages, which are already built, and whose content and design always remain the same.  For Example: About us page of some website. Contact info page of some website Dynamic Web Pages: Dynamic pages are not already defined. They are dependent on search queries. For Example: If we search top 5 books, and click on search button, result would be different. If we search top 5 countries and enter search, result would be different.  So, the search result for every search is different. Working: Now if we have to search static page let's say the first page of any website (which is same for every use in every country) then the process is sim...

OnClick and {}

1. The onClick Mystery: Is it the same? Yes, the concept is 90% the same. If you know how to handle a click in plain HTML/JavaScript, you already know how to do it in React. The logic flow is identical: Event: A user does something (Click). Listener: The element hears it ( onClick ). Handler: A specific function runs to deal with it. The "React Twist" (The 10% difference): There are two tiny syntax differences you must memorize: CamelCase: In HTML, it is onclick (lowercase). In React, it is onClick (camelCase). Function, not String: HTML (Old): onclick="doSomething()" (A string of code). React (New): onClick={doSomething} (Passing the actual function itself). So yes, your intuition is correct: Whenever you need to handle logic (clicks, hovers, typing), you will stick to this pattern: on[Event]={functionName} . 2. The Curly Braces { } : The Portal This is the most important syntax rule in JSX. Imagine your code file has two "Modes": HTML Mode: W...

Servlet Context and Servlet Config

  Problem without init-parameters? Imagine you write a servlet that connects to a database. If you write the database URL, username, and password directly in your Java code, you have a big problem: What if the database password changes? You have to find the code, change it, recompile the .java file into a .class file, and redeploy the entire application. What if you want to use the same servlet in a different project with a different database? You can't. The code is stuck with the old settings. This is where init parameters come in. They let you move this configuration data out of your code and into the deployment descriptor ( web.xml file). How init-parameters help when we use them in web.xml file? They help us in a way that we don't have to find that particular part of code to change it. And also, it saves us the hectic of changing source code and recompiling that again. Anyone with .war file can change the web.xml file  and use it with class file without having the ne...