Add Thingifier API spec and entity views - #84
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: 9d3ab72563
ℹ️ 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".
| if (route.isHiddenFromDocumentation() || route.isDisabled()) { | ||
| continue; |
There was a problem hiding this comment.
When a route is hidden rather than disabled, it remains callable because ThingifierHttpApiRoutings skips only disabled definitions, but this condition removes the hidden verb while rebuilding the endpoint's Allow header. For example, hiding a POST route leaves POST registered while OPTIONS claims it is unavailable; only disabled routes should be excluded from the runtime header.
Useful? React with 👍 / 👎.
| final boolean visible = | ||
| requestSchema | ||
| ? view.isRequestVisible(propertyName) | ||
| : view.isResponseVisible(propertyName); |
There was a problem hiding this comment.
When a view calls disallowInputFields("forbidden") without also hiding that field, this request-schema branch still includes it because it checks only request visibility. Runtime validation separately checks isInputAllowed and returns 422, so the generated OpenAPI schema tells clients they may submit a field the API always rejects; request view schemas need to account for both policies.
Useful? React with 👍 / 👎.
| for (EntityViewDefinition view : objectSchemaDefinition.getViews()) { | ||
| ObjectSchema viewObject = asResponseViewObjectSchema(view); | ||
| components.addSchemas(view.getName(), viewObject); | ||
|
|
||
| ObjectSchema createViewObject = asRequestViewObjectSchema(view); | ||
| createViewObject.title("create " + createViewObject.getTitle()); | ||
| components.addSchemas("create_" + view.getName(), createViewObject); |
There was a problem hiding this comment.
When two entities define the same view name—valid because EntityDefinition enforces uniqueness only within each entity—both views are inserted into the global OpenAPI components map under the same keys. The later entity overwrites the earlier schema, so routes for one entity can reference the other entity's request and response shapes; component names or references need an entity-specific namespace.
Useful? React with 👍 / 👎.
Summary
Tests