[http] Adopt enum-driven visibility #5119
Assignees
Labels
deprecation
A previously supported feature will now report a warning and eventually be removed
feature
New feature or request
lib:http
triaged:core
Milestone
Comments
|
est: 13 |
allenjzhang
added
deprecation
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 22, 2025
This PR brings the core enum-driven visibility system to parity with the existing visibility concepts and uses its new analysis methods in the HTTP and OpenAPI libraries. - Added lifecycle visibility modifiers for `Delete` and `Query` phases. `Delete` applies when a resource is passed as an argument to a DELETE operation. `Query` applies when a resource is passed as an argument to a GET or HEAD operation. - Added lifecycle transform templates for Delete and Query. - Made the logic of applying a visibility filter a little bit more robust. It will consider the `any` constraint of the filter to be satisfied if it is missing OR if some modifier in the constraint is present. If the `any` constraint is present, but empty, it will be unsatisfiable. - Deprecated `getParameterVisibility` and `getReturnTypeVisibility` in favor of `getParameterVisibilityFilter` and `getReturnTypeVisibilityFilter` which return VisibilityFilter objects instead of `string[]`. Like the modifier analysis methods, the filter versions of these methods are infallible. - `getParameterVisibilityFilter` and `getReturnTypeVisibilityFilter` accept a `VisibilityProvider` object that provides default visibility filters for parameters and return types if the parameter/returnType visibilities are not set explicitly. TypeSpec core exports an `EmptyProvider` that always return filters with no constraints, suitable as a default. HTTP exports `HttpVisibilityProvider`, which must be used when working in HTTP, as it provides the HTTP-specific default visibility logic that determines visibility by verb. - `HttpVisibilityProvider` can be instantiated with either an `HttpVerb` directly, in which case that exact verb will be used; `HttpOperationOptions`, in which case the verbSelector will be used if present, otherwise the fallback logic will be used; or no argument in which case the fallback logic will always be used. This gives it parity with `getHttpOperation`. - HTTP now marshals conversions between core visibility and HTTP `Visibility` through visibility filters instead of visibility string arrays. The HTTP Visibility concept is unchanged. - Used new forms of visibility analysis APIs in openapi to detect read-only properties. - ~~Fixed a bug in http-server-csharp that was surfaced by these changes where a visibility constraint `Visibility.Create & Visibility.Update` was provided, resulting in Visibility.None and properties being made invisible, affecting effective type calculation for anonymous models.~~ (invalidated by merge) - Fixed a bug in which `hasVisibility` and `getVisibilityForClass` were improperly initializing the visibility state. This didn't affect the new APIs, but it would cause the state of the legacy APIs to be corrupted if visibility is queried from the new APIs before the legacy APIs. Closes #5119 Closes #5120 --------- Co-authored-by: Will Temple <[email protected]> Co-authored-by: Mark Cowlishaw <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a tracking issue for the HTTP library to adopt enum-driven visibility analysis APIs and implement any enhancements to the core typespec libraries that are required to support the HTTP use case.
See #4825
The text was updated successfully, but these errors were encountered: