The API & integration landscape — a working map for analysts.
Anonymous · the same five statements return at the end of session 4 — we measure the series, not you.
The landscape, the trade-offs, and when an API is the wrong answer.
Requirements, design contribution, and who to contact, consult, or inform.
REST security layer by layer, in a banking context. You spot the weaknesses.
Documentation, testing, lifecycle, risks — and using LLMs safely.
Each session ends by adding its sections to a shared API Integration Analyst Checklist. It stays with you after the series.
Vocabulary → the axis → the landscape → choosing → when not to → your turn.
An API is a door. An integration is the whole delivery route — the truck, the schedule, and what happens when the truck breaks down. "There's an API for that" is where analysis starts, not where it ends.
A request aimed at one system, expecting an outcome: CancelPolicy(123). The caller cares about the answer.
A statement of fact, published to whoever subscribes: PolicyCancelled(123). No response expected — the publisher doesn't know who listens.
A service is a component offering capability — usually through APIs, sometimes by publishing events.
An endpoint without an owner is not an API — it is a future incident. Lifecycle & governance get their own slot in session 4.
The single most important question in any integration discussion: does the caller need the answer to proceed?
worker offline? messages wait in the queue — nobody crashes · failed message retries · poison messages parked in a dead-letter queue
The customer is standing at the terminal. The answer must come now.
Fast matters, but nobody is blocked waiting. Event-driven fits.
Scheduled, bulk, auditable. Batch is the honest answer.
"Real-time" in a requirement is a cost decision. Always ask: how real, measured in what, and what breaks if it's a minute late?
* legacy-leaning, still very much alive · every style gets one to two minutes — depth on request via the parking lot
Representational State Transfer · in practice: JSON over HTTP(S)
$ HTTP/1.1 200 OK Content-Type: application/json { "options": [ { "code": "MTPL-STD", "name": "Mandatory motor liability", "term": "P1Y" } ] }
Simulated call — this fictional insurer API goes live later in the series.
Analyst question: is the need really shape flexibility — or just three missing fields in an existing REST API?
gRPC Remote Procedure Calls · call a function on another system as if it were local
One message → exactly one worker, then it's gone. But what if several systems need to know? Next slide.
Subscribers only hear what happens while they are subscribed. Need history as well? Next slide.
Queue: message consumed → gone. Stream: events remain → readers move. If someone says "Kafka" where you expected "queue", this is the difference they mean.
Recognition level: name it, place it on the map, know its implications, know who to call.
No nostalgia, no disdain — these move real money every night.
naming convention · duplicate-file handling · missing-file alerting · reconciliation of counts and sums
Reading or writing another system's tables (or calling its stored procedures) couples you to its schema and bypasses its business logic and audit. You will still find it.
Extract–Transform–Load (or load first, transform in the warehouse). Bulk data movement into analytics and reporting estates — correct for data pipelines, wrong for transactional process integration.
MQ bridges, file drops, terminal emulation. Recognize the words; escalate the details.
How tightly do the two ends depend on each other?
Latency the business actually needs — not wants.
What may be lost, duplicated, or late?
Who controls each end — and the contract between them?
Build and run effort, including testing.
Data sensitivity, exposure surface, controls required.
Licences, platforms, people — over the whole lifetime.
In the appendix and the analyst checklist — reference material, not memory work.
Scenario: the policy system hands renewal letters to the document service — thousands in a nightly burst, none may be lost, nobody sits waiting.
One left: the message queue — reliable handoff, burst absorption, dead-letter safety net. e.g. RabbitMQ
these five go into the analyst checklist — and your homework API gets the same treatment in session 2
| REST | default request/response; partners; broadest tooling |
| GraphQL | client-shaped reads across several sources |
| gRPC | fast internal service-to-service calls |
| SOAP | the counterpart requires it — formal XML contracts, older vendor & government systems |
| webhook | a provider must push events to you |
| queue | reliable async handoff; burst absorption |
| event stream | high volume, many readers, replayable history |
| file · SFTP | bulk on a schedule; audit-friendly; legacy counterpart |
| ETL · ELT | data movement into analytics and reporting |
| manual · RPA | temporary bridge only — time-boxed, with a written exit plan |
The framework's most valuable output is permission to say no — with reasons, and with an alternative in hand.
Ten recurring cases follow. Each one has appeared in a real project near you.
| when… | reach for… |
|---|---|
| Batch is enough for the business | files · ETL |
| Real-time adds no business value | scheduled exchange |
| A direct API would create tight runtime coupling | events · messaging |
| The source API is unstable or unsupported | file export · wait for a stable contract |
| Event- or message-based fits the flow better | publish / subscribe |
| when… | reach for… |
|---|---|
| An existing connector or iPaaS covers the pair | configure, don't build |
| ETL / ELT is the correct pattern (data, not process) | data pipeline |
| File exchange is simply sufficient | SFTP + reconciliation |
| Manual / RPA (Robotic Process Automation) workaround bridges a gap | time-boxed, with a written exit plan |
| Data ownership is not clear enough to integrate safely | stop — fix ownership first |
Route with the five questions. Disagreement — with me or each other — is a feature.
Nobody here is becoming a developer. The left card is the whole ambition — and every item on it is learnable.
The map, the five questions, the ten "no API" cases, the matrix, the scenarios — plus the analyst checklist that grows each session.
link → on the training page
Pick one integration or API you've had contact with in your organisation. Place it on today's map. Then write down: which questions does it answer for its callers — and one question about it you can't answer yet.
Start part 2 with that API in the back of your head. When we walk through the requirements checklist, test every point against it — that's when what an API really requires clicks.
slides → cybernotes.it/trainings/api-integration/1-integration-landscape · PDF on the same page · part 2: requirements & design — published
| style | coupling | latency | failure isolation | complexity | security surface | typical counterpart | cost |
|---|---|---|---|---|---|---|---|
| REST | med | low | low | low | med | partner or internal | low |
| GraphQL | med | low | low | med–high | med–high | own frontend / BFF | med |
| gRPC | med | very low | low | med | med | internal services | med |
| SOAP | high | low | low | med–high | med | vendor or government | med |
| webhook | low | low–med | med | med | high | provider → you | low |
| queue | low | async | high | med | med | internal systems | med |
| event stream | low | async | high | high | med–high | many internal readers | med–high |
| file · SFTP | low | schedule | high | low | low–med | partner or legacy | low |
| ETL · ELT | low | schedule | high | med | low–med | analytics estate | med |
| direct DB | very high | low | low | low — deceptively | high | legacy · internal | low now · high later |
failure isolation = how insulated you are when the other side is down · security surface = exposure & controls required · coarse ratings on purpose — context beats matrices
| API | Application Programming Interface — a machine-usable interface a system exposes |
| REST | Representational State Transfer — resource-style APIs over HTTP, usually JSON |
| HTTP·HTTPS | the web's transfer protocol · S = encrypted with TLS (Transport Layer Security) |
| JSON | JavaScript Object Notation — the default text format for payloads |
| OpenAPI | the standard machine-readable description of a REST API contract |
| gRPC | gRPC Remote Procedure Calls — fast binary calls over HTTP/2, .proto contracts |
| SOAP | XML protocol with formal contracts (originally Simple Object Access Protocol) |
| WSDL | Web Services Description Language — SOAP's contract file |
| HMAC | hash-based message authentication code — proves who sent a message, unaltered |
| SFTP | SSH File Transfer Protocol — file exchange over an encrypted channel |
| EDI | Electronic Data Interchange — standardized business documents (e.g. EDIFACT) |
| ESB | Enterprise Service Bus — centralized on-premise integration hub (legacy) |
| iPaaS | Integration Platform as a Service — cloud connector platform |
| ETL·ELT | Extract, Transform, Load — bulk data movement into analytics estates |
| RPA | Robotic Process Automation — software robots driving user interfaces |
| DLQ | dead-letter queue — parking lot for messages that repeatedly fail processing |
| BFF | Backend for Frontend — an API layer shaped for one specific client |
| MTPL | Motor Third-Party Liability — the fictional demo API's insurance domain |
not presented live — lives in the PDF as a lookup · security terms (OAuth2, JWT, mTLS …) get their own decoder in session 3