Last updated 3/22/2020 | Personal Opinion

You know a technology is popular when US government writes it in a bill. APIs are such technology mandated in the 21st Century Cures Act, which aims to reduce healthcare cost by exchanging and using electronic health information among doctors, hospitals and health IT developers.

But the APIs today are not my grandpa’s APIs, and its successful implementation takes a village of organizational and engineering practices.


APIs are the contracts between parties, and the parties have evolved through the recent history of enterprise application architectures.

In the old days of monolithic applications where the whole App is just one unit, APIs are the functional interfaces of a software library that’s get built (linked) into and consumed in the consumer process as in-memory calls.

Then came the n-tiered architecture where applications are horizontally partitioned into logical groups of concerns such as representation, business logic and database. APIs in that era took the form of a service, an out of process component that provide answers (responses) to consumer process’ questions (requests). Unfortunately, people over-engineered the API ecosystem and it didn’t get much traction.

Finally, the industry came to the realization that vertically partitioning the applications into functional pieces provides more flexibility and scalability (each piece may further be horizontally partitioned into n-tiers). Since these components are self-contained , independent and small, and they provide services to other components, they assumed the name we are all talking about today: micro-services.

APIs are the service contract of micro-services provided to all their consumers: other micro-services inside an enterprise, third party application developers outside of the enterprise, ad hoc academic researchers…


REST is the most popular but not the only form of APIs. The textual payload and the fine-grained request-response patterns may put a strain on latency and efficiency of APIs. Google developed gRPC and Facebook developed GraphQL to better suit their business needs. I’m not an expert to offer when to use what advice but the point is you should evaluate all options to your specific needs.

Quality of Service (QOS) Concerns

Since APIs are tied to services, the quality of services is commonly the culprit which breaks the promise of APIs in real life applications. Small footprint, low latency, high availability, high scalability are examples of the desirable qualities of service.


If you tell you customers to double the capacity their data center (or pay way more to AWS) to consume your services, you’re in a losing position. That’s why the memory footprint of the micro-services is so important in the fields.

Java the language is dangerous in the sense that it’s so easy to pick up by anybody, it’s easily abused by mediocre or sub-par developers to produce sh*tty code. And by-the-way you need that JVM to tag along with each of your micro-services. One of the companies I worked spent years developing micro-services in Java, only to rip apart and rewrite them with the Go language when the huge footprint is rejected by customers’ IT.


Doctor’s time are precious. If a doctor must wait for more than 7 seconds to view the predicative insights based on a patient’s clinical history, she most likely won’t use the service. Start up and turn-around time of a service all contributes to the latency of an API.

That’s why we need to examine different forms of APIs and employ engineering tricks (e.g. caching) to achieve low latency.


Documentation, testing, CI/CD… Luckily we have tools to cover every aspect of the APIs engineering.


Cloud is the platform to deploy micro-services. AWS, Azure and Google Cloud all provide platforms to support your APIs strategy.

In Summary

Like any piece of software, API must pass different gates which hold different criteria to reach the ultimate user acceptance.


  1. ONC’s Cures Act Final Rule calls on the healthcare industry to adopt standardized APIs(HL7 FHIR), which will help allow individuals and their care providers to access, exchange and use electronic health information.
  2. When to use what: REST, gRPC, GraphQL and Webhooks.
  3. APIs for knowledge transfer and generation in life sciences and health care is a research done by Duke School of Medicine.
APIs: History, Ways and Means

Leave a Reply