fix(133,137): correct Create/Apply HTTP response codes to 201#406
fix(133,137): correct Create/Apply HTTP response codes to 201#406thegagne wants to merge 4 commits intoaep-dev:mainfrom
Conversation
Create should return 201 Created, not 200 OK, per RFC 7231. Apply should return 201 when creating and 200 when updating. The aep-2026 release incorrectly specified 200 for both; this corrects that with should-level guidance to allow backwards compatibility. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
| required: true | ||
| responses: | ||
| '200': | ||
| '201': |
There was a problem hiding this comment.
these examples are generated via aepc: https://github.com/aep-dev/aepc. It would be great to update that first. But I can do so after to align if that's too much effort.
There was a problem hiding this comment.
I'll give it a shot.
There was a problem hiding this comment.
aep-dev/aep-lib-go#15 - I think this needs to happen first unless I'm mistaken?
aep/general/0133/aep.md.j2
Outdated
| **Note:** The aep-2026 release incorrectly specified `200 OK` for Create | ||
| responses. This guidance corrects that: `201 Created` is the appropriate status | ||
| code per [RFC 7231][rfc-7231]. Implementations **should** accept `200` for | ||
| backwards compatibility. |
There was a problem hiding this comment.
I don't think we should include this, as a convention it would litter the spec with a bunch of footnotes. remove?
There was a problem hiding this comment.
The great thing about editions is that the old text lives in the aep-2026 branch.
It might be worth keeping a CHANGELOG of things we've changed, but we can also build that from git logs
There was a problem hiding this comment.
Removed the note. It does clutter it so I agree with removing it, I just wanted to prompt all of us to think through how this could be a breaking change in some cases. While we can accept 200 for backward compatibility, new things being created would not necessarily know about that.
I'm not super worried about it at the moment, but this change could have implications for the lib, the linter, aepc, aepbase, etc., and anyone who uses them.
Our user base is not super large right now and so we can get away with making changes like these, which is nice. I think we just press forward, test things out, and fix them where we can.
3 participants
Summary
Create(AEP-133) should return201 Created, not200 OK, per RFC 7231 §4.3.3Apply(AEP-137) should return201when creating a resource and200when updating200for both; this corrects that withshould-level guidance to allow backwards compatibilityexample.oas.yamlto reflect correct response codes200for backwards compatibilityTest plan
201in the OAS sample200and201in the OAS sample🤖 Generated with Claude Code