Why adopt the AEP specification?

[toumorokoshi]

Oftentimes people ask about why it makes sense to adopt the AEP specification. This is a general thread where we can consolidate such discussions.

[toumorokoshi]

Just some general thoughts:

Regardless of whether it's a public specification, or an internal guideline, there are always going to be debates on the guidance. The advantage that AEPs provide, IMO are:

• the wisdom of the "general tech community" - we have API experts across multiple organizations, so the guidance is a bit harder to argue against. Ones only recourse from a debate standpoint is "the general guidance for X doesn't apply to use because Y", and those are generally weaker technically because it's typically avoiding implementing some feature that's actually valuable, but you're skipping it for velocity purposes (i.e. a global resource storage system and API platform is valuable for organizations, but is very expensive to implement).
• the fact that clients exist that leverage it. If you've invested in the AEP client ecosystem, then almost by necessity you have to follow some subset of the guidance.

[seanlafferty-ibm]

We're AIP users and I love this library https://github.com/einride/protoc-gen-go-aip-test which is a buf plugin to generate go tests for much of the bread-and-butter AIP behavior (can't create the same resource twice, paginated listing eventually iterates all resources, etc)

I think tooling like this is a huge boon to productivity

[toumorokoshi]

Very cool! I think a few folks have brought up that project.

We have been working on an OpenAPI / HTTP+JSON version at https://github.com/aep-dev/aep-e2e-validator. For now, we'll probably get that to production-quality first, then add other ones.

For the proto version I think the einride one is probably pretty close, and nothing is stopping a third party protoc plugin.