Backend & APIs

Authentication answers 'who are you?': proving your identity, usually by logging in. Authorization answers 'what are you allowed to do?': checking whether your account has permission to take a certain action. Both have to pass before sensitive things happen.

A safety rule built into web browsers. By default, a website at one address isn't allowed to grab data from a website at a different address. CORS is the way the second site can say 'it's okay, I trust this other site to read my data.' If the permission isn't there, the browser blocks the request.

The four basic things you can do with stored information: create new items, read existing ones, update them, and delete them. Almost every app you use is built around these four actions, even when they're hidden behind fancier names.

A specific address on a server that does one particular thing when an app talks to it. Each endpoint is like one phone extension at a company: dial it, and you get the person who handles that one task.

A way of asking a server for data where the app says exactly what it wants, no more, no less, in a single request. Instead of getting a fixed bundle of information, the app picks the precise fields it needs, like ordering off a custom menu.

The little verbs that go with every request a browser or app sends to a server. They tell the server what kind of action is happening: GET means 'just give me this thing,' POST means 'create something new,' PUT or PATCH means 'change something,' and DELETE means 'remove it.'

A safety property that means doing the same action twice has the same effect as doing it once. It matters when networks are flaky and the app might accidentally repeat a request: without idempotency, you might end up charged twice for the same thing.

A small, signed pass that an app gives you after you log in. You hand this pass back with every later request, and the server checks the signature to confirm it's really you: without having to look up your account each time.

Code that sits in the middle of a request, doing some prep work before the main action runs. It might check that you're logged in, write a note in the log, or unpack the data you sent: handling the routine stuff so the main code can stay focused on its real job.

A helper that lets a programmer work with database information as if it were everyday objects in their code, instead of writing raw database commands by hand. It saves time and reduces certain kinds of mistakes. Though it can also hide problems if it generates clumsy queries behind the scenes.

A cap on how many requests a single user, app, or computer can make within a window of time. It protects a service from being flooded: whether by accident, abuse, or an automated script that's gone haywire.

A common style for designing the conversation between an app and a server. It treats every piece of information, a user, a post, an order, as a thing with its own web address, and uses simple verbs (get, create, update, delete) to act on it.

A short three-digit number a server attaches to every reply, telling the browser at a glance how things went. Numbers in the 200s mean success, 300s mean 'try over here instead,' 400s mean the request was wrong somehow, and 500s mean the server itself broke.

A way for one service to alert another the moment something happens, instead of the second service constantly asking 'anything new yet?' You give a service your address, and it pokes you whenever an event of interest takes place.

An always-open connection between an app and a server, where either side can send messages to the other at any moment. Normal web requests are like exchanging letters one at a time; a WebSocket is like leaving the phone line open so you can talk back and forth instantly.