“Most developers use APIs every day – but very few actually understand the different types of APIs and when to use them.”
1. The big picture: APIs are everywhere
Whether you are fetching weather data, processing a bank transfer, or validating a login token, you interact with an API. The image attached lists concrete examples – from product fetch to insurance claims and government records. But each of those scenarios uses a different architectural style or visibility level.
Below we structure the two main dimensions: types by architecture (REST, GraphQL, SOAP, etc.) and types by accessibility (internal, partner, open). Then we map the examples from the image to the right category.
2. Who can use the API? (accessibility & visibility)
🔒 Internal API (private / backend‑only)
Used within a company – never exposed to external consumers. Typical flows:
- Backend‑to‑backend communication (microservices talking to each other).
- Frontend‑to‑backend for the same product (the UI calls internal endpoints).
- Service‑to‑database (though often abstracted via a DAL, still internal).
- Examples from the image: login system, token verify, stock update, payment sync – all usually happen via internal APIs before any external exposure.
🤝 Partner API (B2B / affiliate / data sharing)
Exclusively given to trusted business partners. Not public, but accessible outside the company firewall.
- Affiliate integration – e‑commerce partners fetch product feed.
- B2B integration / B2B portal – a supplier updates inventory via your API.
- Commission tracking – ad networks share click/conversion data.
- Healthcare records (FHIR APIs) shared with partner clinics.
- Finance data – accounting software connects to bank APIs (often via partner agreements).
- Logistics tracking – shipment status shared with retailers.
🌐 Open API (public / external)
Available for any developer (often with rate limits or API keys). Image examples that fit here:
- Weather data – OpenWeatherMap or similar.
- Product fetch – e‑commerce public catalog.
- Govt records – open data APIs (data.gov style).
- Sometimes bank transfer or payment sync if offered as open banking (PSD2).
📊 B2B / data sharing (overlaps with partner but broader)
The image explicitly lists “Data Sharing API” and “B2B Integration”. These are often contracted integrations where two companies exchange data – e.g., an insurance claim API used by hospitals, or a finance data feed used by accounting firms.
3. How does the API communicate? (architectural styles)
The image also lists: REST API, SOAP API, GraphQL API. Let’s detail each with use cases.
📡 REST API (Representational State Transfer)
Most common style – uses HTTP methods (GET, POST, PUT, DELETE) and stateless operations.
When to use: general CRUD, web services, mobile backends. Image examples: weather data, product fetch, stock update, login system are almost always REST.
⚙️ SOAP API (Simple Object Access Protocol)
XML‑based, highly structured, with built‑in error handling and security (WS‑Security).
When to use: enterprise scenarios, banking, telecom, government records where strict contracts are needed. Image examples that often use SOAP: bank transfer, insurance claim, govt records, finance data (legacy systems).
📊 GraphQL API
Query language where the client requests exactly the data it needs.
When to use: complex UIs, multiple data sources, mobile apps (bandwidth optimisation). Image examples: product fetch (if frontend needs custom fields), click analytics (aggregations), healthcare records (fetch only required patient fields).
🔁 other styles implied (but not explicitly named)
- Backend‑to‑backend – often uses gRPC or message queues, but also REST.
- Service‑to‑database – not a web API, but internal database drivers (excluded from web API styles).
4. Use‑case matrix: every example from the image classified
The image contains two sections: the left list (plain examples) and the right list (more technical categories). We unify them below.
| Example / use case | Typical API type (access) | Typical architectural style | Explanation |
|---|---|---|---|
| Weather data | Open API | REST (often) | Public data, simple GET requests. |
| Login system | Internal / partner | REST or GraphQL | Usually internal, sometimes exposed as OAuth2. |
| Product fetch | Open / internal | REST / GraphQL | E‑commerce catalogue – can be public or internal. |
| Bank transfer | Partner (B2B) / internal | SOAP or REST (ISO 20022) | High security, often SOAP in legacy banks. |
| Insurance claim | Partner (B2B) | SOAP / REST / EDI | Industry‑specific, strict contracts. |
| Govt records | Open / partner | REST / SOAP | Open data portals (REST) or legacy (SOAP). |
| Payment sync | Internal / partner | REST / webhooks | Between payment gateway and merchant. |
| Token verify | Internal (auth server) | REST / OAuth2 | Introspection endpoint, internal or semi‑internal. |
| Stock update | Internal / partner | REST / message queue | Inventory sync – often real‑time. |
| Affiliate integration | Partner API | REST / XML‑RPC | Commissions, product feeds. |
| Data Sharing API | Partner / B2B | REST / GraphQL / SOAP | General term for controlled data exchange. |
| B2B Integration | Partner | SOAP / REST / EDI | Company‑to‑company automated workflows. |
| B2B Portal | Partner (UI + API) | REST / GraphQL | Web portal for partners, backed by APIs. |
| Healthcare records | Partner / internal | FHIR (REST) / legacy SOAP | Strict compliance (HIPAA). |
| Finance data | Partner / open (open banking) | REST / SOAP | Account aggregation, trading data. |
| Logistics Tracking | Partner / open | REST / webhooks | Shipment status – often real‑time. |
| Commission tracking | Partner (affiliate) | REST / postbacks | Ad networks, track conversions. |
| Click analytics | Internal / partner | GraphQL / REST | Aggregated event data. |
Note: The image also mentions “Internal API” as a category – we already covered it above, and “Open API” is the public face.
5. Deeper: internal communication patterns
The image lists three specific internal patterns:
- Backend to Backend – microservices communicating synchronously (REST, gRPC) or asynchronously (message queues).
- Frontend to Backend – the classic web/mobile app talking to its own server. Often REST or GraphQL.
- Service to Database – not an API in the web sense, but a data layer (JDBC, ORM). Mentioned to show the full stack.
These are all internal API flavors, even if the last one is not a network API.
6. Real‑world scenarios – explained
- Click analytics – an internal API collects page views, then a partner API might share aggregated reports with advertisers.
- Insurance claim + Govt records – often require SOAP due to legal/validation requirements.
- Payment sync – uses webhooks (a kind of API) to notify merchants about transaction status changes.
7. Summary: choosing the right API type
Internal APIs prioritise speed and internal contracts;
partner APIs need strong security and SLAs;
open APIs focus on developer experience. Architecturally,
REST rules the web,
GraphQL empowers flexible frontends, and
SOAP remains in finance/insurance. The image captured a wide spectrum – from weather data (simple REST) to healthcare records (complex, regulated). Use this outline as your cheat sheet.