[http/openapi] Use enum-driven visibility analysis APIs

[witemple-msft]

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.

Closes #5119
Closes #5120

[azure-sdk]

All changed packages have been documented.

• ✅ @typespec/compiler
• ✅ @typespec/http-server-csharp
• ✅ @typespec/http
• ✅ @typespec/openapi

Show changes

@typespec/http - internal ✏️

Updated the OpenAPI3 and HTTP libraries to use the new visibility analysis APIs.

@typespec/openapi - internal ✏️

Updated the OpenAPI3 and HTTP libraries to use the new visibility analysis APIs.

@typespec/compiler - feature ✏️

Added APIs for getting parameterVisibility and returnTypeVisibility as VisibilityFilter objects.

@typespec/http-server-csharp - fix ✏️

Fixed a null visibility constraint when calculating effective type.

[azure-sdk]

You can try these changes here

🛝 Playground	🌐 Website	📚 Next docs	🛝 VSCode Extension