AEP (API Design Standard and Tooling Ecosystem)(aep.dev)
aep.dev
AEP (API Design Standard and Tooling Ecosystem)
https://aep.dev/
10 comments
Any project where all of the links on the first page are “meta” such as “project governance” is my little red flag that tells me there is zero value to be found here.
> If any maintainers stop by this comment section, I suggest offering some explanation about what this project _does_.
This. It's a pretty awful way to present anything. The reader is still clueless and unsure about what they are reading even after navigating through 3 or so links. At each click I was hoping to read anything related to APIs but all I was reading is bureaucrat noise.
Perhaps it's a good idea. I can't tell. I wonder if anyone can.
This. It's a pretty awful way to present anything. The reader is still clueless and unsure about what they are reading even after navigating through 3 or so links. At each click I was hoping to read anything related to APIs but all I was reading is bureaucrat noise.
Perhaps it's a good idea. I can't tell. I wonder if anyone can.
Seconded. And even browsing the actual AEPs, they are presented so confusingly, it's hard to say how it actually works. There's lots of prose, when the first thing I would want to see of a concept is a plain-text HTTP request and response, not a clever Protobuf definition and colored words all over the place.
Start here: https://aep.dev/llms.txt
Is this a clone of the Google AIPs? Like https://aep.dev/160/ seems to just copy https://google.aip.dev/160.
The AEPs were originally based off Google AIPs, but we did a hard fork and have altered a lot since then. For one thing, the AIPs were entirely protobuf focused, while we're focusing equally on protobuf + OpenAPI.
The CRUD methods are great examples where we deviate from the AIPs.
The CRUD methods are great examples where we deviate from the AIPs.
This looks like a useful set of guidelines. I see the most value in reducing the bikeshedding which invariably happens when designing an API. I wonder if anyone is using AEP and can comment on downsides or problems they've encountered.
One thing I've noticed is that the section on batch endpoints is missing batch create/update. Also batch get seems a little strange - in the JSON variant it returns an object with a link for missing entities.
One thing I've noticed is that the section on batch endpoints is missing batch create/update. Also batch get seems a little strange - in the JSON variant it returns an object with a link for missing entities.
I miss the days when "API" meant any programming interface - not just web/rpc - and good API design was about providing the right level of abstraction and making doing the right thing easy and the wrong thing hard, not just CRUD.
I don't know if I just don't get it, but this feels like it's describing... an API?
"Identify standard operations
Section titled “Identify standard operations” Once the resources are defined, identify one or more standard methods for each of those resources. Standard methods operate on the lifecycle of a resource lifecycle: namely, they create, read, update, delete, and list resources."
I mean... yes?
"Identify standard operations
Section titled “Identify standard operations” Once the resources are defined, identify one or more standard methods for each of those resources. Standard methods operate on the lifecycle of a resource lifecycle: namely, they create, read, update, delete, and list resources."
I mean... yes?
- a list of AEPs (explore the AEPs)
- a link to the AEP ecosystem
- a description of how AEPs are built
- a list of AEP clients
- something to do with open standards and versioning
- a blog
and
- a single sentence suggesting the project has something to do with APIs
If any maintainers stop by this comment section, I suggest offering some explanation about what this project _does_.