Think of an API as a waiter who takes your order to the kitchen and brings back your food. It acts as the middleman between you and a database.

The API Waiter Analogy

In this architecture, every piece of information, like a user profile or a photo, is treated as a unique 'thing' or resource.

Resources as Digital Objects

Every resource has its own specific web address, often called an endpoint, so the computer knows exactly where to find it.

This action is used when you want to look at or 'read' information from a system without changing anything.

This action is used when you want to add something brand new to the system, like creating a new account or posting a comment.

This action allows you to replace an entire piece of existing information with a newer version.

Known technically as a PATCH, this action lets you change just one tiny detail instead of replacing the whole record.

This action tells the server to permanently remove a specific piece of information from its system.

A client sends a 'request' asking for something, and the server sends back a 'response' containing the result or an error message.

No matter what part of the system you use, the rules for asking and receiving information stay exactly the same.

These are three-digit numbers, like 404, that quickly tell the computer if the request worked or if there was a problem.

The part you see and the part that stores data are built separately, so one can be updated without breaking the other.

To save time, your device might save a local copy of data it has seen before instead of asking the server for it again.

Your request might pass through security checks or speed-boosting computers before it even reaches the main server.

To keep data safe, APIs use secret keys or digital badges to ensure only the right people can access private information.