How it works
Most web APIs work over HTTP. A client, such as your mobile app, sends a request to an address called an endpoint, with a method that says what it wants: read, create, update or delete. The server checks who is asking, does the work and replies with a status code and data, usually in JSON. REST and GraphQL are two common styles.
| Part | Meaning | Example |
|---|---|---|
| Endpoint | The address you call | /orders |
| Method | The action requested | GET to read, POST to create |
| Authentication | Proof of who is calling | A token sent with the request |
| Response | Status code and data | 200 and a JSON list |
Where you meet APIs
A payment form calls a payment provider's API. A headless CMS delivers content to your site through one. Your own mobile app and website usually share a back-end API, so both show the same data.
Keeping an API safe
An API is a door into your system, so it needs the same care as any screen. Check on every request that the caller may touch that specific record, not just that they are logged in. Validate input, limit how often a client can call, and return only the fields it needs. The OWASP Top 10 and OWASP's separate API Security Top 10 list the usual failures. Our secure app development guide covers the wider method.
Common mistakes
- Checking login but not ownership, so one user can read another user's data by changing an ID.
- Returning whole database records when the app needs three fields.
- Changing an API without versioning, which breaks apps already in use.
- Leaving it undocumented, so every integration becomes guesswork.