Add configurable write method policies - #92
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: da82708858
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| case PATCH: | ||
| apiResponse = thingifier.api().patch(envelope); | ||
| break; |
There was a problem hiding this comment.
When a PATCH route is configured with requestEntityView(...) or entityView(...), this newly added dispatch executes the patch even though validateEntityViewInput returns immediately for every verb except POST and PUT. A client can therefore modify fields that the route's input view marks as disallowed, while equivalent POST/PUT requests receive 422; PATCH must validate the submitted operations or resulting document against the configured input view before dispatch.
Useful? React with 👍 / 👎.
| if (verb == ThingifierHttpApi.HttpVerb.POST | ||
| || verb == ThingifierHttpApi.HttpVerb.PUT | ||
| || verb == ThingifierHttpApi.HttpVerb.PATCH) { | ||
| if (verb == ThingifierHttpApi.HttpVerb.POST || verb == ThingifierHttpApi.HttpVerb.PUT) { |
There was a problem hiding this comment.
When setApiToAllowJsonForContentType(false) is configured, an enabled application/json PATCH now bypasses ContentTypeHeaderValidator and is accepted by RestApiPatchHandler, whereas POST and PUT still return the configured unsupported-content response. Removing PATCH from this condition makes the global request-content policy ineffective specifically for the new write path; PATCH media-type selection should retain the configuration checks while allowing the configured patch media types.
Useful? React with 👍 / 👎.
| RelationshipWriteOperation operation = | ||
| verb == blockedVerb | ||
| ? blockedOperation | ||
| : relationshipOperationFor(verb, route, ApiBodyFields.empty()); | ||
| return operation != null && relationshipOperationsFor(verb, route).contains(operation); |
There was a problem hiding this comment.
When relationship POST is configured for only one operation (for example CREATE_AND_CONNECT) and a request attempts the other operation (CONNECT_EXISTING), the 405 response tests only the blocked operation here and omits POST from Allow. The same relationship collection still supports POST with a creation body—and generated OPTIONS advertises it whenever either POST operation is enabled—so clients receive a contradictory capability header; determine method availability from whether any POST operation is enabled rather than from the rejected body's operation.
Useful? React with 👍 / 👎.
Summary
Validation
Refs #88