F200 TA3: Accessing Data Across Platforms
APIs, interoperability, access control and the cloud: how data gets from one system to another, and who is allowed to see it.
APIs and moving data between systems
An API, an application programming interface, is a defined way for one system to ask another for data or ask it to do something, without either knowing how the other works inside.
A REST API request, in order
- The client sends a request to an endpoint, a URL such as
/api/v1/orders - It uses an HTTP method:
GETto read,POSTto create,PUTorPATCHto update,DELETEto remove - It includes parameters to filter or page the data, and headers carrying the API key or token
- The server authenticates the key, authorises the action, and runs the query
- It returns a status code and a response body, usually JSON
- The client parses the response and handles errors and paging
| Status | Meaning |
|---|---|
200 | OK |
201 | Created |
400 | Bad request: your parameters are wrong |
401 | Unauthenticated: no valid key |
403 | Forbidden: valid key, not allowed to do this |
404 | Not found |
429 | Too many requests: you have hit the rate limit |
500 | Server error: their fault, not yours |
Why an organisation uses an API rather than a file
- Live rather than a snapshot that is stale the moment it is written
- Only the data you asked for, filtered server-side
- Controlled: keys can be scoped, logged, revoked and rate limited
- Stable contract: the provider can change their internals without breaking you
- Auditable: every request is attributable to a key
What to plan for
- Rate limits and the
429response, which means back off and retry later - Paging: large results arrive in pages, and code that reads only the first page silently loses data
- Versioning: build against
/v1/, and watch for deprecation notices - Authentication: keys in a secrets store or environment variable, never in the code or the repository
- Terms of use: an API being technically open does not make the data free to republish
Authentication is proving who you are. Authorisation is what you are then allowed to do. A 401 means the system does not know you; a 403 means it knows you and the answer is still no.
Interoperability and integration patterns
Interoperability is the ability of different systems to exchange data and use it meaningfully. It needs agreement at three levels, and failing any one of them breaks the exchange.
| Level | What has to be agreed | Failure looks like |
|---|---|---|
| Technical | The transport and format: HTTPS, JSON, CSV, SFTP | The file cannot be read at all |
| Syntactic | The structure: field names, nesting, encoding, date format | The file parses but fields land in the wrong place |
| Semantic | The meaning: what "customer" counts as, what "active" means | Everything imports cleanly and the numbers are wrong |
Semantic failures are the dangerous ones, because nothing errors.
Patterns for getting data from A to B
| Pattern | How it works | Suits |
|---|---|---|
| Manual export and import | Somebody downloads a file and uploads it | One-off work only |
| Scheduled batch | A file or extract transferred on a timetable | Nightly reporting |
| API pull | Your system requests data when it needs it | Live lookups, moderate volume |
| Webhook push | Their system notifies yours when something changes | Near real time, low volume |
| Streaming | A continuous flow of events | Sensors, telemetry, fraud detection |
| Direct database access | One system queries another's database | Rarely wise: it couples you to their schema |
Standards that make interoperability possible
Shared formats (JSON, XML, CSV), shared identifiers (ISO country codes, ISBN, UUIDs), shared schemas within a sector, shared character encoding (UTF-8), and shared time representation (ISO 8601 with a timezone). Every one of these exists because somebody's integration broke without it.
Access control, security and the cloud
Controlling who sees what
| Control | What it does |
|---|---|
| Authentication | Establishes identity: password, passkey, certificate, token |
| Multi-factor authentication | Requires something else as well as the password |
| Authorisation | Decides what that identity may do |
| Role-based access control | Permissions attach to roles, and people are given roles |
| Least privilege | Everyone gets the minimum access their job needs, and no more |
| Row and column level security | Restricts which rows or which fields a user can see within one table |
| Audit logging | Records who accessed what, which is itself a control |
| Separation of duties | The person who requests a change is not the person who approves it |
Protecting the data itself
- Encryption in transit: TLS, so an intercepted request is unreadable
- Encryption at rest: the stored file or disk is encrypted
- Hashing: passwords are hashed and salted, never stored or encrypted
- Masking and redaction: showing only the last four digits of a card
- Pseudonymisation: replacing identifiers with a key held separately. Still personal data
- Anonymisation: removing identifiers irreversibly. No longer personal data, and genuinely hard to achieve
- Backup: the 3-2-1 rule, three copies, two media, one off site, and a restore that has actually been tested
Cloud and on-premise
| Cloud | On-premise | |
|---|---|---|
| Cost shape | Operating cost, pay for use | Capital cost up front |
| Scaling | Minutes, and down again | Buy, rack and configure |
| Maintenance | The provider patches the platform | Your team patches everything |
| Resilience | Multiple regions available by default | Whatever you build and pay for |
| Control | Constrained by the provider's options | Complete |
| Data location | Must be chosen and checked | Known by definition |
| Risk | Provider outage, lock-in, misconfiguration | Your own failures, and no one else to call |
Hybrid is the common reality: sensitive or regulated data on premise, elastic analytics workloads in the cloud.
It is a storage bucket left public by mistake. The platform's security was never the weak point; the configuration was. Which is why access review is a scheduled task, not a one-off.
Key terms you must be able to define
- API
- A defined interface letting one system request data or actions from another.
- Endpoint
- The specific URL an API request is sent to.
- API key
- A credential identifying the caller of an API so access can be controlled and logged.
- Rate limit
- A cap on how many API requests a caller may make in a period.
- Interoperability
- The ability of different systems to exchange data and use it meaningfully.
- Webhook
- A message sent by one system to another when an event occurs.
- Authentication
- Establishing who a user or system is.
- Authorisation
- Determining what an authenticated user or system is permitted to do.
- Role-based access control
- Granting permissions to roles and assigning roles to people.
- Least privilege
- Giving each user only the access their role requires.
- Encryption in transit
- Protecting data while it moves across a network, usually with TLS.
- Encryption at rest
- Protecting stored data so the files or disks are unreadable without a key.
- Pseudonymisation
- Replacing identifiers with a separately held key; the data remains personal data.
- Anonymisation
- Irreversibly removing identifying information so data is no longer personal data.
Flashcards
Say the definition out loud before you flip the card. Retrieving it from memory is what builds recall, reading it again is not.
Reach the top grade on this topic
Questions here are nearly always applied. Name the mechanism, then say what attack or failure it prevents and what it costs. "Role-based access control, so a new analyst inherits exactly the permissions of their role rather than being granted them individually, which means access can be audited by role and removed in one change when they leave."
Mistakes that cost marks here
- Treating authentication and authorisation as the same thing.
- Forgetting paging, so only the first page of an API response is ever processed.
- Putting API keys in source code or a public repository.
- Calling pseudonymised data anonymous. If it can be reversed with a key, it is still personal data.
- Describing the cloud as automatically more or less secure, rather than differently configured.
- Claiming a backup exists without ever having tested a restore.
A public API is a promise. When a large platform changes or withdraws one, thousands of applications built on it break at the same moment, which is why serious integrations are versioned and monitored rather than simply used.
Knowledge check
Exam-style questions
Five written questions in the style of the real paper. Write a full answer, then let the marker check it against the mark scheme.
- LA defined interface between two systems
- LWithout either needing to know the other's internal workings, or for data or functionality
An API is a defined interface that lets one system request data or functionality from another, without either system needing to know how the other works internally.
- LAuthentication establishes identity
- LAn example of authentication
- LAuthorisation determines what is permitted
- LAn example, or why the distinction matters
Authentication establishes who a user or system is, using something they know, have or are: a password with a second factor, a passkey, a certificate or an API token. Authorisation then determines what that identity is permitted to do, which is usually expressed through roles, so an analyst can read the sales table but not delete it and cannot see the payroll table at all. The distinction matters because the two fail differently: an HTTP 401 means the system does not recognise you, while a 403 means it recognises you perfectly well and the answer is still no, and fixing one would not fix the other.
- LLeast privilege or role-based access control
- LWhy it is necessary here
- LPseudonymisation or masking of identifiers
- LWhy it is necessary here
- LAudit logging, or row and column level security
- LWhy it is necessary here
The team's access should be role based and set to least privilege: a research role granted read-only access to the specific dataset the approved study needs, rather than individual grants on the live clinical system. That matters because health records are special category data under the UK GDPR, the research purpose is narrower than clinical care, and a role can be audited and withdrawn in one change when the study ends. The data should be pseudonymised before it reaches them, with names, addresses and NHS numbers replaced by a study identifier and the linking key held separately by the clinical team, because researchers almost never need to know which individual a record belongs to and removing that need removes most of the risk. Finally every access should be logged and reviewed, with row level security limiting each researcher to their approved cohort, because logging is what makes misuse detectable and investigable rather than merely prohibited, and a hospital has to be able to evidence who looked at a record and why.
- LCost shape is compared
- LScalability is compared
- LMaintenance and staffing are addressed
- LResilience and backup are addressed
- LSecurity and configuration risk are addressed
- LLegal or data location issues are addressed
- LA clear recommendation is made
- LThe recommendation is justified against the drawbacks raised
The decision turns on five factors. Cost shape comes first: on premise is a capital purchase that has to be sized for the busiest hour of the year and then sits idle, while cloud is an operating cost that tracks use, which suits a company whose volumes are growing and unpredictable but which becomes expensive if a steady, heavy workload is left running continuously. Scalability follows from that: cloud capacity changes in minutes and can be reduced again, whereas on premise growth means specifying, buying, racking and configuring hardware weeks in advance. Maintenance matters more than it first appears, because a growing company rarely has staff to spare: a managed cloud warehouse removes patching, backup and hardware replacement from a small team, and that reclaimed time is a real saving rather than an accounting one. Resilience favours cloud too, since multi-region redundancy and tested restores are available as configuration rather than as a second data centre. Against all that sit two genuine risks. Security does not improve automatically; the dominant cause of cloud data exposure is misconfiguration, so the company would need enforced encryption, role-based access, least privilege and scheduled access reviews. Legally, it must know and control where data physically sits, put a processor contract with appropriate safeguards in place, and check whether any dataset is subject to restrictions on international transfer. My recommendation is a cloud warehouse with a hybrid exception: move the analytical warehouse to the cloud, where the elasticity and reduced maintenance burden genuinely fit a growing company, and keep any regulated or special category data on premise or in a specifically contracted region. That answers the two drawbacks directly, because the configuration risk is addressed by governance the company needs in any case, and the legal risk is addressed by not moving the data that creates it.