AEP (API Design Standard and Tooling Ecosystem)

phrotoma an hour ago | parent | next [-]

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 19 minutes ago \| parent [-]
		> 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.

▲

loevborg 38 minutes ago | parent | prev | next [-]

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.

▲

spenczar5 4 days ago | parent | prev | next [-]

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

	▲	rambleraptor 4 days ago \| parent [-]
		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.

▲

khaledh 20 minutes ago | parent | prev [-]

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.