|
| 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