Open API
1. Overview
A. Definition
An Open API is a publicly exposed standard interface that external developers and services can access and use; by opening up the data and functions an organization holds, it promotes service integration/expansion and an ecosystem (platform).
The essence of an Open API lies not so much in technology as in the "contract." Through the promise that no matter how the internal implementation changes, one need only honor the externally exposed interface (request format, response schema, authentication method), organizations that do not know each other can combine systems without prior negotiation. This "standardized contract" is exactly what distinguishes an Open API from individual point-to-point integration.
B. Background and Necessity
Past systems were closed, so exchanging data with the outside required developing an individual integration (point-to-point) each time. If there are n integration targets, in the worst case one must manage n×(n−1) connections—a combinatorial explosion—and if one system changes, all connected integrations must be modified together, imposing a heavy maintenance burden. This approach becomes rapidly inefficient as the number of participants grows.
In the digital economy, value grows when one service combines with several services (mashup). Examples include overlaying delivery or real-estate information on a map, or combining payment, authentication, and maps to create a new service. Open APIs turn this combination into a standard contract, letting anyone call functions according to a defined specification. In other words, the fundamental necessity of Open APIs is to lower integration costs and increase the speed of innovation.
In particular, the financial sector's open banking and MyData legally mandate API opening, making it a prime case in which Open APIs became not merely a technology choice but industry infrastructure. As account and transaction information that had been closed off per bank was opened via standard APIs, it became possible for fintech firms to provide services that integrate data from multiple financial companies in a single app. This is a case in which Open APIs changed the market structure itself.
C. Characteristics
The characteristics of an Open API are at once its value and its management burden. Openness, standardization, and reusability grow the ecosystem, while because anyone can call it, authentication, billing, and traffic control must necessarily accompany it. That is, the dual proposition of "open, yet controlled" is the essence of operating an Open API, and the point where this is achieved in balance is precisely the API gateway.
| Characteristic | Content | Attendant management task |
|---|---|---|
| Openness | Expose functions/data to authenticated external parties | Access control·permission management |
| Standardization | Comply with standards such as HTTP·REST·OpenAPI (Swagger) | Specification·version management |
| Reusability | Expand mashup·platform ecosystem | Developer portal·documentation |
| Need for control | Authentication·billing·traffic control | API gateway operation |
Standardization in particular is the decisive factor behind the spread of Open APIs. Because there is a common language—HTTP·JSON·the OpenAPI specification—systems built in different languages and platforms can combine without separate adapters. Without standards, one would have to negotiate the format for every integration, making ecosystem expansion itself impossible. In other words, standardization is the foundation that supports reusability and openness.
2. Open API Architecture and Components
An Open API may look like a simple structure in which a client directly calls the resources of an API server, but in an actual operating environment the API gateway serves as the central gate, collectively handling authentication, routing, traffic control, and logging. The structure diagram below shows the process by which a request passes through the gateway to be processed.
flowchart LR
C["Client (app·service)"] -->|HTTPS request| G["API gateway"]
G -->|authn·authz| A["Auth server (OAuth)"]
G -->|rate limit·routing| S["API server (resource)"]
S -->|query·process| D[(data store)]
S -->|JSON response| G
G -->|response·logging| C
G -.monitoring·statistics.-> M["Management·analytics portal"]
The reason for having a gateway is the consolidation of cross-cutting concerns. If authentication, traffic limiting, versioning, and logging were implemented per individual API, duplication and inconsistency would arise, so these are gathered in one place—the gateway—to apply policy consistently. The developer portal serves as a self-service window that catalogs these APIs so external developers can read the specification, get issued a key, and use it right away.
The core components are the resource (identified by URI), the action (HTTP method), the representation (mainly JSON), the auth token (OAuth·JWT), and the gateway·portal that wrap around them. Combined, these complete the contract of "who calls what, how, and in what format the response is received."
Authentication and authorization are the gate of Open API operation. The representative standard, OAuth 2.0, is a delegated-authentication scheme that lets one access a resource with only a delegated access token, without handing the user's credentials (password) directly to a third-party app. The flow below shows the process by which a client obtains a token and calls the API.
sequenceDiagram
participant C as Client
participant Auth as Auth server
participant API as Resource server (API)
C->>Auth: Auth·permission request (scope)
Auth->>C: Issue access token
C->>API: Request resource with token
API->>API: Verify token·check permission
API->>C: JSON response
The core advantages of this scheme are least privilege and ease of revocation. Because a token carries an access scope and an expiration time, even if stolen the scope and duration of damage are limited. Also, permission can be revoked immediately by simply recovering the token, making it far safer than password-sharing. In practice, OIDC (OpenID Connect) is layered on top to standardize authentication (who one is) as well.
3. Comparison of SOAP and REST Components
The two ways to implement an Open API are SOAP and REST. The fundamental difference is that SOAP is a strict XML protocol while REST is an architectural style that uses HTTP as is. This difference creates trade-offs among performance, reliability, and development convenience.
SOAP has strong standards and, with WS-Security and transactions (WS-AtomicTransaction), fits places that need high reliability and security, such as inter-bank transactions. Because messages are heavily wrapped in an XML Envelope and the interface is strictly defined by WSDL, the contract is clear, but the overhead is correspondingly large and it is less flexible. REST, by contrast, expresses resources by URI and handles them with HTTP methods (GET·POST·PUT·DELETE), so it is lightweight, scales horizontally easily because it is stateless, and can use HTTP caching as is.
Because of these differences, most public APIs today are provided via REST (or its alternative, GraphQL). In web and mobile environments, lightness, caching, and scalability are decisive advantages. However, in business-to-business (B2B) and legacy integration that need strong transaction guarantees and standard security, SOAP is still used. That is, rather than "REST is always right," the practical judgment is to choose according to requirements (reliability vs. lightness).
| Category | SOAP | REST |
|---|---|---|
| Concept | XML-based protocol | HTTP-based architectural style |
| Components | Envelope·Header·Body, WSDL, UDDI | Resource (URI)·HTTP method·representation (JSON)·stateless |
| Message | XML | Mainly JSON |
| Security·transactions | WS-Security·WS-Transaction built in | Combined separately with HTTPS·OAuth, etc. |
| Characteristics | Strong standards·transactions·reliability | Lightweight·scalability·caching·stateless |
| Suited for | Enterprise·high-trust·B2B | Web·mobile·public APIs |
4. Vulnerabilities and Countermeasures (OWASP API Security Top 10)
Because Open APIs are exposed externally, they face API-specific threats different from those of web applications. The most common and fatal among them is BOLA (Broken Object Level Authorization), a flaw in which authentication passes but the "permission to access someone else's data" is not verified, so merely changing the identifier in a URL retrieves another person's information.
For example, a logged-in user changes /orders/1001 to /orders/1002 to view someone else's order. The cause is that authentication (who one is) was confirmed but authorization (whether one may access this resource) was not verified per resource. Therefore the server must re-verify ownership/permission of the object on every request, and must not trust the ID the client sent as is. The reason BOLA repeatedly ranks first in the OWASP API Top 10 is that the function works normally, so it is not easily revealed in testing and is exploited only after deployment.
Besides BOLA, major threats include broken authentication, excessive data exposure, resource exhaustion (DoS from unlimited calls), injection, and exposure of neglected old API versions. Most of these share the common cause that "the server trusted client input," so the core of the response is for the server to independently verify all input, requests, and permissions.
| Vulnerability | Principle | Countermeasure |
|---|---|---|
| Broken object-level authorization (BOLA) | Object ownership not verified | OAuth 2.0·JWT + object-level permission verification |
| Broken authentication | Weak token·session management | Standard authn (OAuth·OIDC), token expiry·rotation |
| Excessive data exposure | Response includes unnecessary fields | Minimize response fields, schema validation |
| Resource exhaustion (DoS) | Unlimited calls·bulk queries | Rate limiting·quotas, pagination |
| Injection | Unvalidated input executed as a query | Input validation, parameter binding |
| Improper asset management | Exposure of neglected·old-version APIs | API inventory·version management, block retired APIs |
In fact, incidents in which millions of personal records leaked via BOLA·excessive data exposure have recurred at several large platforms, showing that API security is a problem of the application logic layer, not of the network firewall. Because firewalls·WAFs cannot discern an authorization flaw contained inside a normal request that has passed authentication, API security must be embedded in the service logic.
5. API Management (Lifecycle)
An Open API does not end once published; since external users depend on it, it must be carefully managed from design to retirement. Suddenly changing an API breaks all the services that used it. Thus, at the design stage the contract is defined first with the OpenAPI specification (Contract First), it is published and operated via the gateway·portal, and at retirement a sufficient grace period and migration guidance are provided.
flowchart LR
P["Design (OpenAPI spec)"] --> B["Publish (gateway·portal)"]
B --> O["Operate (authn·billing·monitoring)"]
O --> V["Version management (backward compat)"]
V --> R["Retire (grace·migration)"]
O -.feedback.-> P
The most sensitive point in the lifecycle is version management. Changes that break backward compatibility (deleting a field, changing the response format) are split into a new version (/v2), and the existing version is given a grace period after a deprecation notice so users have time to migrate. Failing to keep this principle collapses trust in the open ecosystem, making external developers reluctant to adopt the API at all.
At the operation stage, monitoring and SLA (service level agreement) management matter. External users depend their own services on the API's availability·response time, so the call volume·error rate·latency metrics the gateway collects must be observed at all times and anomalies detected early. Also, by differentially applying call limits (quotas) and billing policies per usage tier, a surge from a particular user is isolated so it does not degrade the quality of the whole service.
| Stage | Activity |
|---|---|
| Design | OpenAPI spec (contract first), standardization |
| Publish | Register with API gateway·developer portal |
| Operate | Authentication·billing·monitoring·traffic control |
| Version mgmt | Maintain backward compat, split into new version |
| Retire | Deprecation notice·grace·migration guidance |
6. Deep Dive: Latest Trends and Standards
The Open API ecosystem is evolving to match new demands while remaining REST-based. From a professional engineer's perspective, one must understand the following trends together.
- The rise of GraphQL·gRPC: Whereas REST gives a fixed response per resource, GraphQL lets the client query only the fields it needs, solving over/under-fetching of data. Conversely, in microservice internal communication, performance matters, so gRPC, an HTTP/2-based binary protocol, is spreading. That is, public APIs tend to differentiate into REST/GraphQL and internal communication into gRPC.
- Advancement of API gateways·API management (APIM): Beyond simple routing, commercial/open-source APIM (Kong, Apigee, etc.) integrating authentication·policy·billing·analytics has become standard infrastructure and, combined with a service mesh (Istio), controls even internal traffic.
- Application of zero trust·mTLS: Following the zero-trust principle that "even the internal network is not trusted," security is being strengthened toward mutually authenticating the API segment with mTLS (mutual TLS) and verifying·logging all calls.
- Expansion of domestic opening policy: The API opening that began with open banking·MyData is spreading to the public data portal, shared use of administrative information, and more, with Open APIs establishing themselves as core infrastructure of the data economy.
- API-First·documentation automation: As an API-First culture that designs APIs as the top deliverable when planning a service spreads, the approach of auto-generating documentation·SDKs·tests from the OpenAPI specification to secure both consistency and productivity is becoming standard.
7. Considerations and Implications
- Gateway-centric control: Instead of implementing authentication·traffic limiting·versioning·logging per individual API, consolidate them in the API gateway to apply security·operations consistently and reduce the burden on individual services.
- Contract First: Fixing the OpenAPI specification first allows auto-generating documentation·mock servers·client code, enabling development productivity and parallel front-end/back-end development.
- Security is a problem of the application layer: Firewalls alone cannot block logic flaws such as BOLA. One must verify object-level permission on every request and protect the segment with zero trust·mTLS.
- Governance and ecosystem strategy: An Open API is both a technology and a business strategy. Which data to open to grow which partner ecosystem, and how to design billing·SLAs, become platform competitiveness itself. One must consider that opening can change market structure, as with open banking·MyData.
- Trade-offs in standard choice: REST·GraphQL·gRPC·SOAP each differ in their strengths across lightness·flexibility·performance·reliability. Rather than "what is newest," one must choose by comprehensively considering the target (public/internal), requirements (reliability/performance), and user capability; even within a single system it is common to mix different protocols by layer.
References
- OWASP API Security Top 10 — https://owasp.org/API-Security/
- OpenAPI Specification (Swagger) — https://spec.openapis.org/oas/latest.html
- Korea Financial Telecommunications & Clearings Institute, Open Banking — https://www.open-platform.or.kr/
In one line: An Open API is a "publicly exposed contract" based on standards (REST/SOAP·OpenAPI) that expands mashup·platform ecosystems, responds to OWASP API vulnerabilities (especially BOLA) with OAuth·object-level permission verification·gateways·rate limiting, and is operated with contract-first·versioning·retirement lifecycle management and zero trust·mTLS as the foundational infrastructure of open banking·MyData.