Basic Interview question for web developer
Q: What is CORS? How does it work?
CORS adds new HTTP headers that provide access to permitted origin domains. For HTTP methods other than GET (or POST with certain MIME types), the specification mandates that browsers first use an HTTP OPTIONS request header to solicit a list of supported (and available) methods from the server. The actual request can then be submitted. Servers can also notify clients whether “credentials” (including Cookies and HTTP Authentication data) should be sent with requests.
Q: Explain the purpose of each of the HTTP request types when used with a RESTful web service.
Answer: The purpose of each of the HTTP request types when used with a RESTful web service is as follows:
• GET: Retrieves data from the server (should only retrieve data and should have no other effect).
• POST: Sends data to the server for a new entity. It is often used when uploading a file or submitting a completed web form.
• PUT: Similar to POST, but used to replace an existing entity.
• PATCH: Similar to PUT, but used to update only certain fields within an existing entity.
• DELETE: Removes data from the server.
• TRACE: Provides a means to test what a machine along the network path receives when a request is made. As such, it simply returns what was sent.
• OPTIONS: Allows a client to request information about the request methods supported by a service. The relevant response header is Allow and it simply lists the supported methods. (It can also be used to request information about the request methods supported for the server where the service resides by using a * wildcard in the URI.)
• HEAD: Same as the GET method for a resource, but returns only the response headers (i.e., with no entity-body).
• CONNECT: Primarily used to establish a network connection to a resource (usually via some proxy that can be requested to forward an HTTP request as TCP and maintain the connection). Once established, the response sends a 200 status code and a “Connection Established” message.
Q. Explain the basic structure of a MIME multipart message when used to transfer different content type parts. Provide a simple example.
Answer: Each MIME message starts with a message header. This header contains information about the message content and boundary. In this case Content-Type: multipart/mixed; boundary=frontier means that message contains multiple parts where each part is of different content type and they are separated by --frontier as their boundary.
Each part consists of its own content header (zero or more Content- header fields) and a body. Multipart content can be nested. The content-transfer-encoding of a multipart type must always be 7bit, 8bit, or binary to avoid the complications that would be posed by multiple levels of decoding. The multipart block as a whole does not have a charset; non-ASCII characters in the part headers are handled by the Encoded-Word system, and the part bodies can have charsets specified if appropriate for their content-type.
Q. Explain the difference between stateless and stateful protocols. Which type of protocol is HTTP? Explain your answer.
Answer: A stateless communications protocol treats each request as an independent transaction. It therefore does not require the server to retain any session, identity, or status information spanning multiple requests from the same source. Similarly, the requestor cannot rely on any such information being retained by the responder.
In contrast, a stateful communications protocol is one in which the responder maintains “state” information (session data, identity, status, etc.) across multiple requests from the same source.
HTTP is a stateless protocol. HTTP does not require server to retain information or status about each user for the duration of multiple requests.
Some web servers implement states using different methods (using cookies, custom headers, hidden form fields etc.). However, in the very core of every web application everything relies on HTTP which is still a stateless protocol that is based on simple request/response paradigm.