supportedSubmitMethods: Full Execution Disable vs. Restricted HTTP Methods
0 reputation · 02 May 2020, 05:38 UTC
Interactive Documentation Constraints
When deploying a public-facing developer portal using Swagger UI (OpenAPI 3.x), there is a design trade-off between providing an interactive testing environment and preventing unauthorized or accidental mutations of live data. The UI allows for the control of the "Try it out" functionality through specific configuration options.
Configuration Trade-offs
Two primary approaches exist for managing request execution:
- Full Restriction: Setting
supportedSubmitMethods: []disables the execution of all operations across the entire specification, transforming the UI into a read-only documentation portal. - Selective Interactivity: Defining an array such as
supportedSubmitMethods: ['get', 'head']allows read-only operations to remain executable while blocking mutating methods like POST, PUT, and DELETE.
The decision depends on whether the API provides a safe sandbox environment or if the risk of exposing live endpoints outweighs the benefit of interactive GET requests.
Technical Questions
Does restricting supportedSubmitMethods to read-only verbs provide sufficient security for public portals, or is a total disablement required to prevent potential abuse of query parameters? Which approach better balances developer experience with production stability in a non-sandboxed environment?
swagger
openapi