Skip to main content


Port 80 (HTTPS is 443).

HTTP/1 to HTTP/2 to HTTP/3 -

Status codes

npm package:


  • 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:

Zalando status codes:

401 Unauthorized vs 403 Forbidden


RFC 9110 HTTP Semantics - (old)

MethodRequest has bodySuccessful response has body
DELETEMay, but is ignoredMay

Source: Also see the table at

Body in GET and DELETE requests should be ignored

Idempotent and Safe

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:

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

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



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.



The 'authority' is

Uniform Resource Identifier (URI): Generic Syntax: