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

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

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

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

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

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