An API type classifies an interface by its interaction model and technical conventions. Choose it according to user needs, exposed capabilities, consumers, architecture, and operational context rather than defaulting to a familiar stack. section 1.6.2 section 14.8
REST is a common choice: identify business concepts such as User and Status, convert operations such as “Share a message” into POST /statuses, and model inputs and outputs such as a string-valued message. Identify capabilities before discussing HTTP so technical conventions do not obscure user needs or business processes. section 1.6.2 section 3.1.5
Match interaction requirements to API types:
- Use SSE when consumers need streamed data. section 14.8.2
- Use WebSockets when communication must be bidirectional. section 14.8.2
- Consider event-driven architecture when sending events to internal systems. section 14.8.2
- Consider GraphQL for a backend-for-frontend when its specific features provide value beyond a well-designed REST API over HTTP/2. section 14.8.2
Real-time product prices
If shopping partners must know about product price changes in real time, requiring them to reread every product each second is likely unsuitable. Streaming or event-oriented communication may better fit the requirement than a conventional REST polling design. section 14.0 section 14.8.2
Evaluate alternatives against user needs, efficiency, security, and design consistency. Also account for browser compatibility, internet communication, public or partner exposure, existing systems, and consumer limitations; different contexts can justify different API types. section 14.8.2 section 16.2.2
