Building an API engine

Pipi will use its content management system (CMS) to generate Application Programming Interfaces (API) for internal use.

There was a prototype built in 2018 for Pipi 6.

I need to get this working and in production, so these are notes for the job.

From Wikipedia

"An application programming interface (API) is a way for two or more computer programs or components to communicate with each other. It is a type of software interface, offering a service to other pieces of software.[1] A document or standard that describes how to build or use such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation. Whereas a system's user interface dictates how its end-users interact with the system in question, its API dictates how to write code that takes advantage of that system's capabilities.

In contrast to a user interface, which connects a computer to a person, an application programming interface connects computers or pieces of software to each other. It is not intended to be used directly by a person (the end user) other than a computer programmer who is incorporating it into the software. An API is often made up of different parts which act as tools or services that are available to the programmer. A program or a programmer that uses one of these parts is said to call that portion of the API. The calls that make up the API are also known as subroutines, methods, requests, or endpoints. An API specification defines these calls, meaning that it explains how to use or implement them."


Martin Catterall got me started with API in 2018 and was a great sounding board.


  • Come up with a robust architecture/data model that can be easily extended using a plugin for each API type.
  • Any plugin can be a 3rd-party open-source application (GitHub).
  • Pipi can use this to automatically build internal API.
  • Do these first
    • 1 REST 
    • 2 GraphQL
    • 3 SOAP
    • 4 DDS
    • 5 gRPC


  • Open as possible
  • Well documented
  • Comply with standards
  • Reliable, secure, and fast
  • Work with multiple types of API
  • Can be versioned
  • Can scale


  • Design and Build Great Web APIs by Mike Amundsen. 2020, The Pragmatic Programmer.
  • Enterprise API Management by Luis Weir. 2019, Packt.


Examples to test


This is my hierarchical list of API types. Is this a good classification?
  • Webservice
    • REST
  • Object remoting
    • DCOM
    • CORBA
    • EJB
  • RPC
    • Apache Avro
    • Apache Thrift
    • gRPC
    • GraphQL
    • JSON-RPC
    • SOAP
    • XML-RPC
  • Event Streaming
    • CICS
    • DDS
    • EDI
    • RSocket
    • WebSocket


These are the specification languages used to describe API. This list is incomplete. What is missing? Wikipedia article on interface description languages.
  • Taffy (The REST Web Service Framework for ColdFusion and Lucee)

No comments:

Post a Comment