Definition
An API (Application Programming Interface) is a defined set of rules, protocols and endpoints that lets one piece of software interact with another — sending requests, receiving responses, and exchanging structured data — without either party needing to know the other's internal implementation.
APIs are the connective tissue of modern software. Every time your app talks to a payment processor, a third-party CRM, an AI model, or a SaaS service, it does so via an API. The quality of those APIs — their reliability, latency, documentation, and consistency — determines whether the integration is straightforward or a swamp.
Modern web APIs are typically REST or GraphQL over HTTPS, returning JSON. RPC patterns (gRPC, JSON-RPC) are common in internal microservice architectures. The choice between styles depends on the use case — REST for public-facing simple resources, GraphQL when clients need flexible querying, gRPC when raw performance matters.
Origin
The term API dates to the 1960s mainframe era. The modern web API pattern emerged with Roy Fielding's REST dissertation (2000), and the SaaS-API ecosystem exploded through the 2010s as cloud services became default infrastructure.
How it works
- Define what the API needs to do — what resources or actions does it expose?
- Choose a style (REST, GraphQL, gRPC, RPC) based on use case.
- Design endpoints, request/response schemas, authentication, error responses.
- Document with OpenAPI/Swagger or equivalent.
- Build, test, and ship with versioning from day one.
- Monitor uptime, latency, error rate; iterate based on consumer feedback.
When to use it
Use when
- Whenever software needs to talk to other software.
- When exposing functionality for third-party integration.
- When splitting a monolith into services.
Skip when
- For internal helpers that never cross a process boundary.
- When direct database access is genuinely simpler and the access pattern won't change.
Key metrics
- Uptime SLA
- Average response latency
- Error rate by endpoint
- Documentation completeness
- Developer adoption (for public APIs)
Examples
- Our public API uptime hit 99.99% last quarter — that's the SLA our enterprise customers actually pay for.
- The third-party API's docs were so bad we spent three weeks reverse-engineering responses.
- We migrated from REST to GraphQL for the mobile client and request count dropped 70%.
In practice at Makreate
Makreate AI Web App and Mobile App engagements build API-first from day one. Every product we ship has a clean internal API even when there's no current need for an external one — because the next CRM integration, the next mobile client, the next BI tool will all need an API, and adding one later is harder than designing one in. We document everything in OpenAPI, version from v1, and treat the API as a product surface, not an afterthought.
AI Web App Development →Common mistakes
- Designing the API around the database schema instead of the consumer's mental model.
- Not versioning from the start.
- Skipping documentation — undocumented APIs are unusable APIs.
- Inconsistent error response shapes across endpoints.
- Not monitoring API latency and error rates over time.
Frequently asked
What's the difference between REST and GraphQL?
REST exposes resources via fixed endpoints. GraphQL exposes a query language clients use to ask for exactly the data they want. REST is simpler; GraphQL is more flexible for diverse clients.
Do I need to build a public API?
Only if you have external consumers (third-party developers, customer integrations, public SDKs). Internal APIs between your own services are usually plenty.
How do I handle API breaking changes?
Version explicitly (v1, v2, ...), deprecate old versions with long lead time, and document migration paths clearly.