It's All About the Database

Popular APIs or “Communication is Everything”

Each time you use a social media app, send an instant message, or check the weather on your phone, you are using an API.

API is an acronym for Application Programming Interface. It is software that sits between applications and programmatically allows them to “talk” to each other.  A bridge of sorts. APIs’ are critical, standardized components for integrating applications and data.

Use Case

There are lots of popular APIs from companies you know and love for adding weather forecasts, maps, and directions, taking payments and enhancing security to custom websites.  Additionally, developers need APIs for building custom databases for doing things like analyzing social media feeds.

Businesses like APIs.  They save time and money.  

Over the past two decades the internet spawned several popular APIs now in use, mainly:  SOAP, REST, and gRPC.

SOAP an acronym for Simple Object Access Protocol is a messaging protocol developed by Microsoft in the late 1990s-early 2000s.  A messaging protocol is a set of rules and a defined data format for sending “messages” between applications.

SOAP uses an XML data format. If your not familiar, XML or “Extensible Markup Language” is a set of rules or “tagged content” for creating messages. A sample SOAP message that a stock quote app might use would look something like this:

Most if not all, modern operating systems, and programming languages support XML. It travels easily over the internet from source to destination through firewalls and proxies.  SOAP XML messages need the Hypertext Transport Protocol (HTTP) to send XML data between sources and destinations.  

SOAP Slips

SOAP is less "simple" than the name suggests. It can be complex, requires bulky XML data and lots of network bandwidth.  Large XML files can be painfully slow to process.  Around ten years ago as a response to these issues’ developers started migrating away from SOAP towards REST.

REST or Representational State Transfer (REST) is not a protocol but a software design “style”.  It defines an approach for creating web services. As mentioned above, web services allow developers to easily add ready to use, third-party features like weather forecasts, maps, directions, payments, and annoying ads to custom websites.

Compared to SOAP, REST is easier to use.  It is light weight and scalable.  REST message data, usually in JSON format easily moves across HTTP:

REST data is “stateless”. That is a server does not save any data pertaining to the client or source request. The client saves this “state data” on its end. For the most part, REST has become the de facto design pattern for web services.

RESTlessness

Issues with REST include:

1. Lack of Security – REST does not impose any sort of security like SOAP. This is why REST is very appropriate for public available URL's, but when it comes down to confidential data being passed between the client and the server, REST is not a good choice.

2. Lack of state – Most web applications require a stateful mechanism. For example, if you have a purchasing site that uses a shopping cart, you need to know the number of items in the cart before the actual purchasing of anything. Unfortunately, the burden of maintaining this state lies with the client, which just makes the client application heavier and more difficult to maintain.

RPC

RPC or remote procedure call is a computer program that runs a process on a remote computer.  It is coded as if it were running on the calling or local computer. The approach has been around for over 50 years.

gRPC

Around ten years ago Google built “Stubby” a single general-purpose RPC to connect the large number of microservices running in Googles’ data centers. In March 2015, Google decided to build the next version of Stubby and make it open source. The result was gRPC, which is now used in organizations outside of Google to power use cases from microservices to the “last mile” of computing  like mobile, web, and Internet of Things(IoT).  Square, Netflix, Cisco and others now use it.

gRpc features:

1. Protocol Buffers.  Protocol buffers are what XML is to SOAP or JSON is to REST but smaller, faster, and simpler.  It uses non-readable, binary data and is up to ten times faster than REST or SOAP.  
2. HTTP/2 support. Introduced in 2015, HTTP/2 is a major revision of the HTTP1.1 transport protocol.  All current versions of popular web browsers now support it.  gRPC takes advantage of it.
3. Multi-language support. You can build gRPC applications with

4. Auto-code generation.  Programming languages like C# automatically generate code needed for running a gRPC application.

What’s Best?

It depends.   Developer and author Kristopher Sandoval agrees.   If you need security, high performance in a B2B setting then gRPC may be your ticket.  REST is the most popular and still may be best for consumer to business (C2B) apps.

The door to continue using SOAP however is shutting. Microsoft is not supporting SOAP on .Net. If your running SOAP your due for an upgrade.  Migrating from SOAP to gRPC is possible.  There are some tools out there to help automate the process.

Be Well.