API Variants

A LinkedIn post by Reshma Sriraman (31 October 2026) explains that checking the weather, logging in to an app, making a payment or tracking an order all rely on APIs, but that APIs are not all built for the same purpose. It first classifies APIs by who they are built for. Open APIs give external developers or applications access to specific services and data, usually with authentication and usage limits, for example weather data, login integrations and product information. Internal APIs connect systems and services inside an organization, for example employee profile management, backend-to-backend communication, and database operations and reporting. Partner APIs give controlled access to selected business partners, for example banking and payment integrations, insurance claim processing, and affiliate platforms with commission tracking. The post then separates this from API styles and communication approaches: REST uses HTTP methods to work with resources, SOAP uses structured messaging that is commonly XML-based, and GraphQL lets clients request the specific data they need. These are a different classification from open, internal and partner. The post says choosing the right approach matters when building applications, integrating enterprise systems or developing AI agents. This page organizes specifications, standards, security guidance and tools around those two classifications, and adds a few other common styles as clearly separate extras. Descriptions are paraphrased from each source and are not rankings.

Who the API is built for decides how it is secured, documented and governed.

REST uses HTTP methods to work with resources.

SOAP uses structured messaging that is commonly XML-based.

GraphQL lets clients request the specific data they need.

Additional styles often seen alongside REST, SOAP and GraphQL.

Authentication, authorization and testing apply to every API variant.