AEP (API Design Standard and Tooling Ecosystem)

AEP (API Design Standard and Tooling Ecosystem)(aep.dev)

35 points by rambleraptor 69 days ago | 10 comments

phrotoma 65 days ago |

On the landing page one can find:

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

locknitpicker 65 days ago | |

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

9dev 65 days ago | |

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.

jiggawatts 64 days ago | |

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.

Terretta 65 days ago | |

Start here: https://aep.dev/llms.txt

spenczar5 69 days ago |

Is this a clone of the Google AIPs? Like https://aep.dev/160/ seems to just copy https://google.aip.dev/160.

rambleraptor 68 days ago | |

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.

loevborg 65 days ago |

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.

khaledh 65 days ago |

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.

bleudeballe 65 days ago |

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?