aep.dev
aep.dev copied to clipboard
aep-dev
AEPs help developers and organizations build clear, consistent network APIs and clients by providing an extensible set of design guidelines.
Adopt AEP 231 - Batch Get ## 🍱 Types of changes What types of changes does your code introduce to AEP? _Put an `x` in the boxes that apply_ -...
I really don't like this annotation - it's very confusing, and it basically means that the behavior of the field isn't always an input. I think there's actually a quick...
We should clarify what the impact of following must vs should guidance is - specifically that not following must will lead to breaking auto-generated clients.
> It's unclear to me if we need an OpenAPI extension, but I'd guess we do? We definitely need OpenAPI variants - I'll file an issue at least. _Originally posted...
Is there an issue to track this as needing OpenAPI? _Originally posted by @earth2marsh in https://github.com/aep-dev/aep.dev/pull/139#discussion_r1527569246_
AEP-154 has a discussion around [strong and weak etags](https://aep.dev/154#strong-and-weak-etags). This Is referencing the existence of the concept in [RFC 7232](https://datatracker.ietf.org/doc/html/rfc7232#section-2.1). I worry that allowing support of both strong and weak...
I'm not entirely sure. I guess since HTTP calls is content-type, we should follow suit? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type I don't think we should be constrained by legacy - if there's backwards-incompatible changes...
Sorry, I'm referring specifically to the guidance that update can return partial resources. Yes I'll file an issue on this. _Originally posted by @toumorokoshi in https://github.com/aep-dev/aep.dev/pull/115#discussion_r1524257312_ Sorry, I'm referring specifically...
create by necessity can't have a path in the request, at least not a required one: that would deviate in the case of server-generated fields. In general apply is a...