HTTP

The application layer protocol of the internet, port 80 or 8080

Methods

So common b/c in past browsers just supported these two

HTTP method

RFC

Request has Body

Response has Body

Safe

Idempotent

GET

Optional

Yes

Yes

Yes

POST

Yes

Yes

No

No

Status Codes

  • Informational 1XX

  • Successful 2XX

    • 200 Ok

    • 201 Created

    • 204 No Content

  • Redirection 3XX

    • 304 Client's copy of a resource is still valid

  • Client Error 4XX

    • 400 Bad Input

    • 401 Unauthorizaed

    • 402 Payment required.

    • 403 Forbidden

    • 404 Not found

    • 422 Unprocessable Entity

  • Server Error 5XX

Headers

Request

Content-Type

'content-type': 'multipart/form-data; boundary=...'
Content-Type: text/html; charset=UTF-8

multipart/* requires the boundary parameter so server can parse payload

Accept request HTTP header advertises which content types, expressed as MIME types, the client is able to understand.

Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*

Cookies

If you want to support most browsers, then don't exceed 50 cookies per domain, and don't exceed 4093 total bytes per domain

Often used to store sessions, just store session/user id in a cookie with a signature

A cookie with no expiration date specified will expire when the browser is closed i.e session key set to true.

Servers set cookies withSet-Cookie header

Browser sends cookies with Cookie header

Cookie properties to control domains sent to:

  • Secure: This will ensure that cookies can only be sent to HTTPS servers.

  • Domain: A list of hosts that a cookie can be sent to.

  • Path: Similar to Domain but restricts the cookie from being sent to URLs that do not include the Path.

Cookies are sent with every request to the server, even those from other sites :O, this can lead to CSRF where another website tricks the user into sending a get/post request to your server with their auth.

Design

Most common is Rest Resources with some rpc like functions calls thrown in

Rest

  • REST, mostly about defining resources at an endpoint like /event that you can then do get, create, update, in an idomatic way.

  • Relies heavily on HTTP defaults like caching

  • Ideal is complete decoupling of client and server (HAL, JSON-API, etc)

  • Large payload sizes often requiring many http calls to populate a page

  • Best for most general use case with many clients, clear documentation, and focus on objects/resources

event/1/question to add to an id

GraphQL

  • Instead of modeling fts or resources, you model queries.

  • Can specify the specific data you want

  • Strongly typed schema sending queries

  • Most Complex, but low coupling and high efficiency especially for graphs

  • Best for graph-like data and weak, decoupled clients like mobile

RPC

  • Basically everything is a function you call like listEvents?id=1, more common actually. gRPC is a very effiecient google implementation based on HTTP/2.

  • More efficient, but more tight coupling

  • Great for internal microservices sending secure messages

  • Best for action-oriented and simple interactions like Slack join or leave channel. Best for efficiency with little metadata

PreviousFeature FlagsNextIDs

Last updated