Let’s go back to basics and remind ourselves that a database schema is a collection of metadata that defines the relationships between tables, fields, objects, and information found within a database. The schema helps define a database, acting as a guide to help programmers properly navigate their way through tables, views, procedures, and more.

Now think of an API. An API is an interface that allows two disparate chunks of software, services, or platforms to transact with each other through a request-response message system.

How convenient would it be for developers if they had the equivalent of a database schema for an API?

Various industry bodies have been working on standardizing application integration since the 90s when web services were introduced. The SOAP protocol was an attempt to create some standards for working with web services.

Lessons Learned From SOAP

For a while, the Simple Object Access Protocol (SOAP) was considered the ‘god’ of messaging protocol for web services. Its operation and input parameters were documented in a schema called a Web Service Definition Language (WSDL).

Over time, it became harder to work with a web service without a WSDL, making it almost like a prerequisite for SOAP. However, over the years, SOAP became increasingly verbose making its use more burdensome.

As the quest for faster, lighter, and better web-based apps emerged, developers turned to the REST architecture to address these issues from SOAP.

REST stands for REpresentational State Transfer. It is very much the architecture behind designing networked applications. REST relies on a stateless communications protocol, such as HTTP.

Because of this, REST is easier to use, more flexible, and a lot faster, making it a very attractive option for APIs. RESTful APIs (which are web services that implement REST) are widely seen as the lean savior for loosely coupled systems.

#integration #api #soap #ipaas #openapi #openapi documentation