Sections

Building an API engine

Mike's Notes

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.

Resources

References

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

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

17/05/2025

Building an API engine

By: Mike Peters
On a Sandy Beach: 06/02/2024

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

"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." - Wikipedia

Thanks

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

Priorities

  • 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

And

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

Websites

  • SOA Tech Magazine

Wikipedia

  • API

Examples to test

  • https://github.com/XeroAPI/Xero-OpenAPI
  • programmableweb.com
  • RapidAPI.com
  • apilist.fun
  • ifttt.com
  • elastic.io
  • Postman

Classification

This is my hierarchical list of API types. Is this a good classification?

  • https://www.mulesoft.com/resources/api/types-of-apis
  • 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

Interfaces

These are the specification languages used to describe API. This list is incomplete. What is missing? Wikipedia article on interface description languages.

  • GraphQL
  • SDL
  • REST
  • API Blueprint
  • OData
  • OpenAPI
  • RAML
  • SOAP
  • WSDL

CFML

  • Taffy (The REST Web Service Framework for ColdFusion and Lucee)

No comments:

Post a Comment