Skip to main content

HTTP

Port 80 (HTTPS is 443).

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

https://developer.mozilla.org/en-US/docs/Web/HTTP

https://github.com/for-GET/http-decision-diagram

https://httptoolkit.tech/blog/http-wtf/

Status codes

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

https://httpstatuses.com

https://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html

https://www.restapitutorial.com/httpstatuscodes.html

npm package: https://github.com/prettymuchbryce/http-status-codes

Categories

  • 1xx informational response – the request was received, continuing process
  • 2xx successful – the request was successfully received, understood, and accepted
  • 3xx redirection – further action needs to be taken in order to complete the request
  • 4xx client error – the request contains bad syntax or cannot be fulfilled
  • 5xx server error – the server failed to fulfil an apparently valid request

Common codes

Status CodeStatus MessageCommentsSpec
200OKFor GET and POST requests typicallyRFC 7231
201CreatedFor POST and PUT requests typicallyRFC 7231
204No ContentUse it if the response has no body. For PUT, PATCH and DELETERFC 7231
304Not ModifiedThe client (browser) gets the resource from its own cacheRFC 7232
400Bad RequestSome parameter is missingRFC 7231
401UnauthorizedNot properly authenticated
403ForbiddenNot authorized to access the resourceRFC 7231
404Not FoundRFC 7231
405Method Not AllowedRFC 7231
409ConflictUsername or email already existsRFC 7231
500Internal Server ErrorRFC 7231

Stripe common status codes: https://stripe.com/docs/api/errors

Zalando status codes: https://opensource.zalando.com/restful-api-guidelines/#http-status-codes-and-errors

401 Unauthorized vs 403 Forbidden

https://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses

Methods

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

RFC 9110 HTTP Semantics https://www.rfc-editor.org/rfc/rfc9110.html#name-methods - (old) https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods

MethodRequest has bodySuccessful response has body
GET
POST
PUTMay
PATCH
DELETEMay, but is ignoredMay

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods. Also see the table at https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods

Body in GET and DELETE requests should be ignored

Idempotent and Safe

https://stackoverflow.com/questions/45016234/what-is-idempotency-in-http-methods

https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Safe_methods

Idempotent: can be applied multiple times without changing the result beyond the initial application (source).

Safe: it doesn't alter the state of the server, ie performs a read-only operation.

All safe methods are also idempotent, but not all idempotent methods are safe. For example, PUT and DELETE are both idempotent but unsafe.

Rule: never change state with a GET. See GET Don't Let Users Confirm Via HTTP GET. It can have bad consequences: https://stackoverflow.com/questions/50365264/users-browser-seems-to-trigger-requests-multiple-times-a-day

GET, HEAD, OPTIONS and TRACE methods are defined as safe, meaning they are only intended for retrieving data. This makes them idempotent as well since multiple, identical requests will behave the same source

MethodDescriptionIdempotentSafe
GETReadYesYes
POSTCreateNo - we create new records every time unless there's some duplicated field validationNo
PUTUpsert. Replace existing record entirely or create it. Requires sending all fieldsYes - we can perform it multiple times, only the first PUT will take effectNo
PATCHPartially update existing record. Does not require sending all fieldsNo - surprising, see why belowNo
DELETEDeleteYes - we can delete the same record multiple timesNo

Why PATCH is not idempotent

See https://stackoverflow.com/a/39338329/4034572

From https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PATCH

A PATCH is not necessarily idempotent, although it can be. Contrast this with PUT; which is always idempotent. The word "idempotent" means that any number of repeated, identical requests will leave the resource in the same state. For example if an auto-incrementing counter field is an integral part of the resource, then a PUT will naturally overwrite it (since it overwrites everything), but not necessarily so for PATCH.

URI

scheme://user:password@host.com:8080/path/file?querykey=queryvalue#fragment

The 'authority' is user:password@host.com:8080.

Uniform Resource Identifier (URI): Generic Syntax: https://www.ietf.org/rfc/rfc3986.txt