[–] cbarrick 2mo ago ↗ This is a fork of Google's AIPs (API Improvement Proposals) [1], which is the standard for all of Google's public APIs.More context at [2].[1]: https://aip.dev [2]: https://aep.dev/blog/history-of-aeps/
[–] agentik 2mo ago ↗ https://news.ycombinator.com/item?id=48126889 just posted a thread, for a compeletly unrelated AIP definition :)
[–] endtime 2mo ago ↗ I worked on this for a couple years (have been much less active lately), surprised to see it on the front page of HN but happy to answer questions about it.
[–] thegagne 2mo ago ↗ Happy adopter of AEP here.It has been super helpful and the ecosystem is growing around it.The real benefit is having a standardized pattern for APIs, with automation and predictability built in.Not everything can be modeled as a resource, but for any API that fits that, it’s fantastic.It’s a bit restrictive at times, but those restrictions often shed light on bad architecture/data modeling.They worked through a lot of feedback last year and cut a 2026 LTS release to give strong confidence to start building tooling around it.Check out https://aepbase.io/ for an example and fun way to get started.
4 comments
[ 3.1 ms ] story [ 15.7 ms ] threadMore context at [2].
[1]: https://aip.dev [2]: https://aep.dev/blog/history-of-aeps/
It has been super helpful and the ecosystem is growing around it.
The real benefit is having a standardized pattern for APIs, with automation and predictability built in.
Not everything can be modeled as a resource, but for any API that fits that, it’s fantastic.
It’s a bit restrictive at times, but those restrictions often shed light on bad architecture/data modeling.
They worked through a lot of feedback last year and cut a 2026 LTS release to give strong confidence to start building tooling around it.
Check out https://aepbase.io/ for an example and fun way to get started.