Skip to content

Commit 8e34b04

Browse files
authored
commit blog post to aeps directory (#267)
This commits our first blog post to the aeps directory. The site-generator doesn't currently take in the blog posts, but this PR is a prerequisite.
1 parent 63768ee commit 8e34b04

File tree

1 file changed

+159
-0
lines changed

1 file changed

+159
-0
lines changed

blog/2024-in-review.md

Lines changed: 159 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,159 @@
1+
---
2+
title: AEP's 2024 Year in Review
3+
date: 2024-12-19
4+
authors:
5+
- name: Mak Ahmad
6+
- name: Alex Stephen
7+
- name: Yusuke Tsutsumi
8+
---
9+
10+
# Building Better APIs Together: AEP's 2024 Year in Review
11+
12+
As we close out 2024, we want to share the significant strides the API
13+
Enhancement Proposals (AEP) project has made in creating a more cohesive API
14+
ecosystem. What started as a fork of Google's API Improvement Proposals has
15+
evolved into something much more ambitious: an open, community-driven standard
16+
for building resource-oriented APIs that work consistently across different
17+
protocols and platforms.
18+
19+
A brief summary of the achievements outlined below are:
20+
21+
- The creation of aepc, an AEP "compiler" that takes a succinct resource
22+
definition and generates protobuf and OpenAPI schemas.
23+
- The 0.1 release of aepcli, which can consume aep-compliant APIs and generate
24+
a resource-oriented command-line-interfaces dynamically.
25+
- A complete linter for protobuf APIs, and starting an OAS variant.
26+
- aep-explorer: a prototype of a WEB UI to explore aep-compliant APIs.
27+
- A redesigned website (aep.dev), where this blog post is published!
28+
29+
## The Vision Takes Shape
30+
31+
This year clarified our core belief that API design shouldn't be a bikeshedding
32+
honeypot. By collecting hard-won design patterns from across the industry,
33+
we've worked to narrow the decisions API producers need to make while improving
34+
the experience for API consumers. Our approach focuses on resource-oriented
35+
design principles that can be expressed in both Protocol Buffers and OpenAPI,
36+
making AEPs protocol-agnostic while maintaining strong opinions about what
37+
makes APIs more usable and maintainable.
38+
39+
## Major Technical Achievements
40+
41+
### aepc: The AEP compiler
42+
43+
We introduced [aepc](https://github.com/aep-dev/aepc), our service compiler
44+
that transforms concise resource definitions into fully-specified APIs. With
45+
just a few dozen lines of YAML describing your resources and their
46+
relationships, aepc generates complete Protocol Buffer and OpenAPI
47+
specifications that adhere to AEP standards. This dramatically reduces the
48+
boilerplate needed to create consistent APIs while enforcing best practices
49+
through generation rather than just validation.
50+
51+
aepc is just a prototype with no official release at this moment, but it has
52+
been very useful, producing AEP-compliant OpenAPI and protobuf specifications
53+
that are used as examples in the specification.
54+
55+
### aepcli: A Command-Line Interface for Everyone
56+
57+
The launch of version 0.1 of [aepcli](https://github.com/aep-dev/aepcli) marked
58+
a significant milestone in our tooling journey. Rather than requiring every API
59+
provider to build their own CLI, aepcli dynamically generates a powerful
60+
command-line interface from any AEP-compliant API's OpenAPI specification. This
61+
client-side approach means new API features are immediately available without
62+
requiring CLI updates, solving a common pain point in API tooling.
63+
64+
### aep-explorer
65+
66+
To complement our command-line tools, we developed a web-based UI for browsing
67+
and interacting with AEP-compliant APIs:
68+
[aep-explorer](https://github.com/aep-dev/aep-explorer) . This provides a more
69+
visual way to understand and experiment with APIs while maintaining the same
70+
consistent interaction patterns that make AEPs valuable.
71+
72+
### Enhanced Linting Capabilities
73+
74+
A major focus this year was improving our linting capabilities, particularly
75+
for OpenAPI specifications. Mike Kistler led the effort to revitalize our
76+
[OpenAPI linter](https://github.com/aep-dev/aep-openapi-linter), implementing
77+
rules for key AEPs including AEP-132 (List methods) and AEP-135. The linter
78+
helps teams validate their APIs against AEP guidance, catching common issues
79+
early in the development process.
80+
81+
Significantly progress was also made for our
82+
[protobuf linter](https://github.com/aep-dev/api-linter), which is now
83+
compliant with all of the updated guidance in aep.dev.
84+
85+
The linter's approach balances pragmatism with standards enforcement \- while
86+
some rules are mandatory, others can be selectively adopted based on an
87+
organization's needs. This flexibility helps teams gradually adopt AEP
88+
practices while maintaining consistent APIs. The project uses Spectral as its
89+
foundation, allowing teams to build on an established tooling ecosystem while
90+
adding AEP-specific validations.
91+
92+
To help teams get started, we've included comprehensive test cases and example
93+
APIs that demonstrate proper implementation of AEP patterns. The linter has
94+
already helped identify areas where our documentation needed clarification,
95+
particularly around operation IDs and resource naming conventions.
96+
97+
### Improved Infrastructure
98+
99+
A major focus this year was improving the components used for learning about
100+
the AEP standards and enforcing them in our organization.
101+
102+
To help teams get started, we've built comprehensive test cases and example
103+
APIs that demonstrate proper implementation of AEP patterns. The linters have
104+
already helped identify areas where our documentation needed clarification,
105+
particularly around operation IDs and resource naming conventions.
106+
107+
Additionally, we've built out a new aep.dev website based on a new framework to
108+
help highlight our guidance and to help the team release new content over time.
109+
110+
## Community Growth
111+
112+
### The March Barn Raising
113+
114+
On Pi Day (March 14), we held our first community "barn raising" event,
115+
bringing together contributors from across companies and time zones. The event
116+
focused on improving documentation, adding OpenAPI examples, and making AEPs
117+
more accessible to newcomers. This collaborative effort helped us identify and
118+
address gaps in our guidance while strengthening our community bonds.
119+
120+
### Expanding Global Reach
121+
122+
Recognizing our growing international community, we established EU-friendly
123+
meeting times and welcomed contributors from companies like DoubleVerify,
124+
providing valuable feedback on real-world AEP adoption. This led to
125+
improvements in our documentation and examples, particularly around pagination
126+
and custom methods.
127+
128+
### Educational Content
129+
130+
We launched the [@aepdev](https://www.youtube.com/@aepdev) YouTube channel
131+
featuring detailed demonstrations of our tooling and explanations of AEP
132+
concepts. These videos help newcomers understand both the technical details and
133+
the broader vision of what we're building.
134+
135+
## Looking Forward to 2025
136+
137+
As we enter the new year, our focus areas include:
138+
139+
1. Expanding our linting tools across both Protocol Buffer and OpenAPI
140+
specifications
141+
2. Building more client generators, including Terraform providers and
142+
Kubernetes operators
143+
3. Working with the OpenAPI community on resource-oriented API patterns
144+
4. Supporting more companies in adopting AEPs, with clear migration paths and
145+
tooling support
146+
147+
## Get Involved
148+
149+
We're building AEPs in the open and welcome contributions of all kinds. You can
150+
join us:
151+
152+
- On CNCF Slack in the \#aep channel
153+
- At our weekly community meetings (Fridays at 11:30am PT)
154+
- On GitHub at [github.com/aep-dev](https://github.com/aep-dev)
155+
- Through our documentation at [aep.dev](https://aep.dev)
156+
157+
Whether you're building new APIs or working to improve existing ones, we
158+
believe AEPs can help make that process more consistent and maintainable. Join
159+
us in building better APIs together\!

0 commit comments

Comments
 (0)