Which Javascript Apis Do You Know?

What are the types of APIs and their differences?

Enterprises increasingly rely on APIs to interact with customers and partners. It all starts by knowing which type of API is right for your needs.

Stephen J. Bigelow

Stephen J. Bigelow,

Published: 08 Feb 2021

The API is a powerful and versatile means to connect diverse and disparate software applications. APIs allow a vast array of unrelated software products to integrate and interoperate with other software and data. APIs also allow developers to add features and functionality to software past utilizing a rich array of other developers' APIs.

APIs are not all equal, however. Developers can piece of work with an assortment of API types, protocols and architectures that suit the unique needs of unlike applications and businesses.

Four types of spider web APIs

APIs are broadly accepted and used in web applications. There are iv master types of API ordinarily used in web-based applications: public, partner, private and composite. In this context, the API "type" indicates the intended scope of utilise.

Public APIs. A public API is open and available for utilize by any outside developer or concern. An enterprise that cultivates a business concern strategy that involves sharing its applications and data with other businesses will develop and offering a public API.

Public APIs typically involve moderate authentication and authorization. An enterprise also may seek to monetize the API by imposing a per-call cost to use the public API.

Partner APIs. A partner API, only bachelor to specifically selected and authorized outside developers or API consumers, is a ways to facilitate business-to-business activities. For example, if a business wants to selectively share its customer data with exterior CRM firms, a partner API can connect the internal client data system with those external parties -- no other API use is permitted.

Partners have articulate rights and licenses to access such APIs. For this reason, partner APIs more often than not incorporate stronger authentication, authorization and security mechanisms. Enterprises likewise typically do not monetize such APIs directly; partners are paid for their services rather than through API use.

Internal APIs. An internal (or individual) API is intended simply for apply inside the enterprise to connect systems and data within the concern. For instance, an internal API may connect an organization'south payroll and HR systems.

Internal APIs traditionally present weak security and authentication -- or none at all -- because the APIs are intended for internal utilize, and such security levels are causeless to be in identify through other policies. This is changing, yet, as greater threat sensation and regulatory compliance demands increasingly influence an organization'due south API strategy.

Blended APIs. Composite APIs by and large combine two or more than APIs to arts and crafts a sequence of related or interdependent operations. Blended APIs tin can exist beneficial to accost circuitous or tightly-related API behaviors, and can sometimes improve speed and functioning over individual APIs.

API protocols and architectures

APIs exchange commands and data, and this requires clear protocols and architectures -- the rules, structures and constraints that govern an API'southward performance. Today, there are three categories of API protocols or architectures: REST, RPC and Lather. These may be dubbed "formats," each with unique characteristics and tradeoffs and employed for different purposes.

REST. The representational state transfer (Residual) architecture is perchance the most popular approach to building APIs. Residue relies on a customer/server approach that separates front and back ends of the API, and provides considerable flexibility in development and implementation. Residue is "stateless," which means the API stores no data or status betwixt requests. REST supports caching, which stores responses for irksome or non-fourth dimension-sensitive APIs. Residual APIs, usually termed "RESTful APIs," likewise can communicate directly or operate through intermediate systems such as API gateways and load balancers.

RPC. The remote procedural call (RPC) protocol is a simple ways to send multiple parameters and receive results. RPC APIs invoke executable actions or processes, while REST APIs mainly exchange data or resource such equally documents. RPC tin can employ two different languages, JSON and XML, for coding; these APIs are dubbed JSON-RPC and XML-RPC, respectively.

SOAP. The simple object admission protocol (SOAP) is a messaging standard defined past the World wide web Consortium and broadly used to create web APIs, ordinarily with XML. SOAP supports a wide range of communication protocols found across the cyberspace, such as HTTP, SMTP and TCP. SOAP is also extensible and fashion-independent, which allows developers to write Lather APIs in varied ways and easily add features and functionality. The SOAP approach defines how the Soap bulletin is processed, the features and modules included, the advice protocol(southward) supported and the construction of SOAP messages.

Compared with the flexibility of REST, Soap is a highly structured, tightly controlled and clearly defined standard. For instance, SOAP messages may incorporate up to four components, including an envelope, header, body and error (error handling).

Comparing API protocols

The choice of an API format can have a profound and long-lasting affect on the success and adoption of an API. Organizations must select the most advisable format based on the complication of the information that must be exchanged, the level of security needed around that information and the speed or performance required from those exchanges.

For example, a simpler format may be easier to code and maintain, but might not offer the level of security, such as encryption, that an enterprise adopter requires. More complex formats might provide that security, only pose college learning curves for adopters or require more bug fixes and piece of work from developers. The tradeoff is rarely simple, but in that location are some common considerations for the major API formats.

Consider Remainder and Lather. Both formats are designed to connect applications and mainly use HTTP protocols and commands such as GET, POST and DELETE. Both can use XML in requests and responses. Nonetheless, SOAP depends on XML by design, while Residual can also use JSON, HTML and plain text. Soap is standardized with strict rules, while Rest allows flexibility in its rules and is instead governed by architectures. Lather is congenital from remote procedure calls, while REST is based on resources.

Thus, both REST and Lather substitution information, but practise then in very different ways. Soap is used when an enterprise requires tight security and clearly defined rules to support more complex data exchanges and the ability to call procedures. Developers frequently utilize Lather for internal or partner APIs. REST is used for fast exchanges of relatively simple data. REST can also support greater scalability, supporting large and agile user bases. These characteristics make REST pop for public APIs, such every bit in mobile applications.

REST	SOAP
Works with XML, JSON, HTTP and plain text	Works with XML by pattern
Loose and flexible guidelines based on architectures	Strict, conspicuously-defined rules
Small-scale security	Advanced security
Works well with data	Works well with processes (deportment)
Uses low bandwidth and is highly scalable	Uses more bandwidth with limited scalability

The word well-nigh when to utilise RPC is a bit simpler. Similar to Lather, RPC is highly structured and intended for relatively elementary APIs capable of invoking processes. The pick then is whether to use JSON or XML -- and over again, it depends on the API's intended purpose, the types of data to exchange and the required level of security. JSON is the simpler linguistic communication, and JSON-RPCs support but alphanumeric data (text) exchanges with little security. XML-RPC handles a wider range of data, including text, images, graphs and charts, and more. Thus, XML offers superior document handling capabilities and offers amend security features than JSON. Both approaches support a diverseness of programming languages, including Python, Coffee and PHP.

Ultimately, RPC-based APIs are a poor pick for enterprise-grade APIs considering of their limited data type support and express security. However, they may be suitable for some internal composite APIs. For example, JSON-RPC APIs tin can make calls without awaiting a response, and support multiple simultaneous calls that can be handled asynchronously.