The startup I work for is making a transition into a microservices-based architecture. I'm working with a Senior Engineer to design a new backend platform based off our current monolith.

We plan on having a bunch of REST API endpoints in containers that DevOps will orchestrate using Kubernetes. The current plan is to use Python3 and Falcon; we are open to using Go (or PyPy) on a container-by-container basis if performance becomes an issue.

Very exciting! But I do feel like I'm a bit over my head.

We all know imposter syndrome is part of being a developer. The only way to fight it is to fake it until you make it.

Learn as much as you can every single day. Get out of your comfort zone by working on challenging projects. Share what you know with others to cement your knowledge. You may never lose that feeling of being a phony, but at least you'll be in a better position than before.

In my new series called Deep Dives, I will research a topic and present my findings in a semi-detailed blog post; think end-result of a research spike.

This is the first in a multi-post arc exploring the Hypertext Transfer Protocol, more commonly known as HTTP. I'll start with a brief introduction into the protocol and cover topics like HTTP headers, verbs, and status codes in subsequent posts.

HTTP is an application layer protocol for transmitting hypermedia documents. It follows the client-server model of communication where a client opens a connection to make a request and waits until it receives a response.

HTTP is stateless which means that neither the client nor the server retains information about the messages that were sent / received. If we want to provide context for communication, we need to include additional information each time a request is made. HTTP cookies allow for stateful sessions.

When a web browser goes to a document, it triggers a bunch of requests to fetch all the sub-documents contained in the main resource. Once all the information is downloaded, the browser can render the initial document as described.

• Workflow:
  • user-agent sends a request
  • server processes request, sends back a response

The client only sees server endpoints; all the information about the underlying implementation (load balancer, cache, DB, schema, etc) should be abstracted away behind the endpoint.

There are also proxies which relay HTTP messages between the client and server, these proxies must not alter request methods, but they do have the ability to change some headers.

HTTP Messages

Request

Consist of:

• HTTP Method (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH)
• Path of resource to fetch
• Version of HTTP protocol
• Optional headers to provide the server with additional information
  • format: Header: value
  • General headers - apply to message as whole
  • Request headers - give request context or conditionally restrict it
  • Entity headers - applies to the body of the request (i.e. Content-Type)
• Optional body which contains resource
  1. Single-resource bodies - Single file defined by two headers (Content-Type and Content-Length)
  2. Multiple-resource bodies - Multiparty body each containing different kind of information, associated with HTML Forms.

Example Request:

GET / HTTP/1.1
Host: alysivji.com
Accept-Language: en

Response

Consists of:

• Version of HTTP protocol
• Status code and message
• Headers
  • format: Header: value
  • General headers - apply to whole message
  • Response headers - give additional information about server
  • Entity headers - apply to the body of the request
• Optional body containing fetched resources
  1. Single resource bodies of known length - Defined by two headers (Content-Type and Content-Length)
  2. Single resource bodies of unknown length - Encoded with chunks (Transfer-Encoding:chunked)
  3. Multiple resource bodies - Consist of a multipart body each with different information

Example Response:

HTTP/1.1 200 OK
Last-Modified: Sun, 19 Nov 2017 00:00:55 GMT
Content-Type: text/json

{
    "key": "value",
}

HTTP Cookies

Cookies are (key, value) pairs that store session state. They are initially sent from the server to the user's browser where they are stored. The browser then sends the cookie back with all subsequent requests.

Cookies are used for three purposes:

• Session management
• Personalization
• Tracking

Creating Cookies

A server can send a Set-Cookie header with a response

Types of Cookies

• Session cookie - deleted when the client shuts down
• Permanent cookie - can set Expires or Max-Age to have it persist when client closes
• Secure and HTTPOnly cookies - only sent to the server with an encrypted request over HTTPS
• Zombie cookie - HTTP cookie that is recreated after deletion

Scope of cookies

• Domain and Path directives define scope of cookie and where it can be sent

Cross-Origin Resource Sharing (CORS)

Excerpt:

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain) than the site currently in use. A user agent makes a cross-origin HTTP request when it requests a resource from a different domain, protocol, or port than the one from which the current document originated.

An example of a cross-origin request: A HTML page served from http://domain-a.com makes an src request for http://domain-b.com/image.jpg. Many pages on the web today load resources like CSS stylesheets, images, and scripts from separate domains, such as content delivery networks (CDNs).

HTTP/2 Frames

• HTTP/2 introduces an extra step into the workflow, it divides the HTTP/1.x messages into frames which are then streamed.
• Works when both browser and server have HTTP2 enabled.

Additional Resources

• HTTP: Hypertext Transfer Protocol