What it is
The most common way to build an API: every entity has its own address, and actions are ordinary HTTP requests to get, create or change it. The answer usually comes in JSON.
How we use it
The online store's REST API is written in FastAPI: catalogue, orders, site settings. The Tech Poly VPN bot drives the Marzban panel through its REST API and keeps money, terms and discounts itself.
Where it helps a business
- The storefront, a bot and the owner's panel must work with the same data through one entry point.
- A bot has to drive another system: create users, extend access.
- A mobile app or customer account takes its data from your server.
How we use it
- A store API. In the online store a FastAPI REST API serves the catalogue, takes orders and stores the site settings; both the storefront and the owner's panel work through it.
- Driving a panel. The Tech Poly VPN bot creates, renews and subscribes users in Marzban through its REST API, while it keeps money and terms itself.
Common problems
- Open routes. Every route that changes something must check sign-in. In the store, all write routes check authorisation.
- Exposing too much. On WordPress after the move from Joomla, the user list in the REST API is hidden so it cannot be used to guess logins.
- Trusting submitted data. The server recalculates prices and the order total from the database rather than taking them from the request.
When you do not need it
If a site is pages of text with no logic of its own, a separate API is unnecessary. For events a service should report by itself, a webhook is better.