A REST API is a particular way of writing that contract for the web. Each thing you care about — a customer, an order, a payment — gets an address. You read it, create it, change it, or remove it with the ordinary verbs of the web. The answer is usually a small block of JSON, which is just labelled text a program can read.
Addresses and verbs
If the customer is a thing the business recognises, it should have a stable address. Asking for that address returns the customer. Sending a change to that address updates the customer. You do not invent a private dialect for every project if the ordinary verbs already say what you mean. That is why REST spread. A developer who has never seen your company can still call it, log it, and show you the exact request that failed.
The style is a convention, not a law. Plenty of useful interfaces are "REST" in the proposal and a pile of oddly named calls in the code. Judge the list of addresses and the document that explains the fields. Ignore the badge.
What it is bad at
REST is a poor fit when one screen needs twenty related facts and you would otherwise make twenty calls. A report that joins orders, stock, and tax is often happier as one purpose-built call than as a tour of every resource. People reach for other styles at that point. You do not need that argument on day one. You need the ten calls the business actually makes.
It is also not a security model. A public address with no key is an open drawer. Authentication, a limit on how often a caller may knock, and a version so you can change a field without breaking last year's app are the parts that keep it alive. They are dull. They are the work.
When it matters
Choose this style when a website, a mobile app, or another company must talk to a system you own. It is the default we use on .NET systems that expose orders, stock, or a customer record. It matters less inside a single screen that only your own code will call. Start from the plain meaning of an API, then insist on a written list of addresses before anyone builds the second client. Splitting the system into microservices is a later decision. A clear REST surface does not require that split.