Join our Newsletter — 33% off our NHI Course

API Types

API types are the ways systems expose functions and data for software to consume. In identity and security work, they commonly include REST, SOAP, GraphQL, and event-driven APIs, each shaping how authentication, authorization, rate limits, and token handling are enforced across applications, services, and non-human identities.

What API Types Determine in Practice

API types are not just labels for interface styles, they shape how a system exposes capabilities, how clients are expected to interact with it, and where security controls must be enforced. The type you choose affects authentication flows, request structure, data exposure patterns, and how consistently policy can be applied across services.

In security work, the practical question is usually not whether an API is “REST” or “GraphQL”, but how the chosen type changes trust boundaries, access decisions, and monitoring. A design that is easy for developers can still create broad data access paths, ambiguous authorization checks, or inconsistent rate limiting if the API style is not governed carefully.

Common API Types and Their Security Characteristics

REST, SOAP, GraphQL, and event-driven APIs are common patterns, but each creates a different security posture. REST usually maps well to resource-oriented access control, SOAP often brings stronger message-level structure in enterprise environments, GraphQL can concentrate access into a single endpoint with flexible queries, and event-driven APIs introduce asynchronous delivery and subscription concerns.

Those differences matter because attackers and misconfigurations often exploit the shape of the interface. A highly flexible API can increase the chance of over-fetching, broken authorization, or excessive data exposure, while a tightly structured API may be easier to validate but still vulnerable if authentication and authorization are weak.

For an authoritative security lens on these patterns, OWASP API Security Top 10 is the most direct reference because it focuses on API-specific failure modes such as broken authorization and resource abuse.

Why API Types Matter for Authentication and Authorization

The API type often determines where credentials are presented, how tokens are validated, and whether access checks happen at the edge, at the object level, or inside business logic. That is why the same identity system can behave very differently across API styles even when the underlying users or services are unchanged.

In practice, this means an API type can influence whether coarse controls are sufficient or whether the design requires object-level, function-level, or query-level enforcement. It also affects token propagation, session boundaries, and how much trust is placed in client-side filtering versus server-side enforcement.

When organisations need a broader control baseline around authentication, access control, auditability, and configuration discipline, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control catalogue most often used to anchor those requirements.

Operational Trade-offs in API Design and Governance

API types also influence operational decisions such as versioning, throttling, schema governance, error handling, and observability. An API that supports ad hoc queries or event fan-out may be more flexible for product teams, but it can be harder to inventory, secure, and monitor consistently at scale.

Governance therefore has to follow the interface model, not just the application owner. That includes deciding how schemas are approved, which data fields are exposed by default, how abusive request patterns are detected, and which consumers are allowed to call which endpoints or subscribe to which events.

For zero trust design principles around verifying access continuously and minimizing implicit trust between services, NIST SP 800-207 Zero Trust Architecture is a useful companion reference.

How to Evaluate API Types During Security Review

A security review should start with the API inventory, then map each API type to its exposure level, consumer population, and enforcement model. The key question is whether the design makes authorization easy to prove and hard to bypass, especially when the same backend capability is exposed through multiple interface styles.

Reviewers should also ask whether the interface type increases the blast radius of a credential, token, or service account compromise. Some API designs localize access cleanly, while others make broad data retrieval or function invocation possible from a single endpoint or subscription path.

For teams that need a practical identity baseline for API consumers, NIST SP 800-63 Digital Identity Guidelines helps frame assurance, authenticator strength, and the quality of the authentication step that precedes API access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP API Security Top 10 API5 — Broken Function Level Authorization API types affect how function-level access is enforced across endpoints.
API1 — Broken Object Level Authorization Resource-oriented and query-based APIs commonly fail at object access enforcement.
Recommendation — Review each API type for function-level authorization gaps before exposing business actions. Enforce object-level checks on every API request, regardless of interface style.
NIST SP 800-53 Rev 5 AC-3 — Access Enforcement API access depends on enforcing permissions at the service boundary and object level.
IA-2 — Identification and Authentication (Organizational Users) API consumers often depend on organizational authentication before access is granted.
AU-2 — Event Logging API type influences what must be logged for access, queries, and abuse detection.
Recommendation — Apply access enforcement at the API layer and verify every protected operation server-side. Require strong authentication before allowing organizational users to invoke API functions. Log API access and security-relevant events with enough detail to support investigation.