Concluding Thoughts

The language-oriented approach seeks to address the cascade of challenges organizations face when trying to create an API program that follows a design-first approach. It tries to make organizational language the primary tool for designing APIs. Moreover, it encourages organizations to create small tools to accomplish their design goals.

We need a shift like this in our industry. It's too complicated for organizations to implement and maintain a good API program. We've been down this same path with API design tooling for many years now with the hopes of improving the process of designing and building APIs. We've yet to reach this goal, leaving us with a complex and fragmented API industry that creates more questions than answers.

The path forward needs to be about creating languages that suit business needs, an idea borrowed directly from Language-Oriented Programming (LOP). LOP, as Wikipedia defines it, is:

[...] a software-development paradigm where "language" is a software building block with the same status as objects, modules and components, and rather than solving problems in general-purpose programming languages, the programmer creates one or more domain-specific languages (DSLs) for the problem first, and solves the problem in those languages."

We see the same goal in the Semantic Web as its goal is to "enable people to create data stores on the Web, build vocabularies, and write rules for handling data." In the Semantic Web, we overlay language onto existing formats and technologies. We also see the same goal with Eric Evan's work on Domain-Driven Design, which Martin Fowler says of it, "At the heart of [Domain-Driven Design] was the idea that to develop software for a complex domain, we need to build Ubiquitous Language that embeds domain terminology into the software systems that we build."

These other approaches share this common thesis: people get the most benefit in their software practices when they align their code and architecture as closely as possible to the language of the problem domain. The language-oriented approach is about following this path of making language the center of interaction. Language is all we have when we design APIs, and by not making our process language-oriented, we bury the details and limit the ability of API designers to the subset of knowledge they have about existing general-purpose standards and tools. The language-oriented approach constrains the language to that of the organization—not to limit the API designer, but to accelerate the API design process and foster conversation that aligns with the organizational language.

Lastly, the goal of this short book is not only to formalize a new idea, but to trigger new ideas in others. If someone else takes the ideas from the language-oriented approach and builds upon them, or if the language-oriented approach influences modern standards and tooling in a way that makes them more language-oriented, this work will be considered a success.