Home/Expertise/REST APIs & integration
REST APIs & integration
Business-critical applications tend to accumulate data and logic that nothing else can reach. Integration then happens by scheduled file transfer, a shared database login, or a person exporting a spreadsheet every Monday.
The upgrade
None of these arrangements were mistakes. They were the cheapest thing that worked at the time — and each one quietly became a constraint on the system underneath.
A job writes a file, another job picks it up, and the data is correct as of last night. When something goes wrong nobody notices until a person does, and the failure mode is silence.
An API answers with current data, and a failed call is an error somebody can see.
The most expensive integration there is. Every other system now depends on your table structure, so the schema can never change — and none of your business rules are applied to what they write.
An API is a contract you control, which means the internals become free to change again.
Someone runs a report, adjusts it, and sends it on. It works, it is invisible in every architecture diagram, and it stops entirely when that person is on holiday.
Automating it is usually the fastest payback of the three.
The data exists, another department needs it, and the answer has always been that the system cannot do that. Often the logic is already there — it simply has no door.
This is the case where an API creates capability rather than just tidying one up.
Method
The temptation is to expose the database. It is fast to build and it recreates exactly the coupling you were trying to escape.
An endpoint should mean something to the business — approve, release, reprice — not mirror a table. Tables change; business operations mostly do not.
The rules in the application are the rules. Reimplementing them behind the API creates two sources of truth that will disagree within a year.
The hardest question in a legacy API. A caller that retries must not create the order twice, so idempotency has to be designed rather than hoped for.
The moment another team depends on the API, changing it becomes their problem too. Versioning added later is a migration; added at the start it is a path segment.
Questions
Usually far less than people expect. The common shape is a thin service alongside the existing application that reuses the same business logic and the same database.
The application itself keeps running unchanged while the API is built and tested, which also means the first release carries very little risk.
No. A nightly bulk file transfer is a perfectly good design for a nightly bulk transfer, and replacing one with an API called a million times is a downgrade.
REST earns its place when callers need current data on demand, or when you need a contract you control instead of direct access to your internals.
With authentication and authorisation designed for who is actually calling it — service-to-service credentials, tokens, or integration with whatever identity system you already run.
The important part is that permissions are enforced in the API rather than assumed from network position. "It is only reachable internally" tends to stop being true before anyone updates the diagram.
The integration work is largely the same regardless of what is on the other end: agree the contract, map the data, decide what happens when one side is unavailable, and make failures visible rather than silent.
Tell us what the other system is and we will say plainly how familiar we are with it. We would rather scope the learning curve honestly than claim a product experience we do not have.
Next step
Describe what needs to reach what, and how the two currently exchange data. That is usually enough to say whether this is a small job or a real project.
