Preserve Authentication and Header context when switching between API resources in Developer Portal

Current behavior in the Developer Portal forces a complete refresh of the right-side frame (Try-it panel) whenever a user switches between different API resources or methods. This causes all previously entered data—specifically Authorization tokens, custom Headers, and Parameters—to be cleared or reset.

While this is "working as designed" according to current documentation, it creates a significant friction for developers who need to test multiple endpoints within the same API session.

Proposed Change : We propose implementing a "sticky" context or a state-preservation mechanism for the "Try-it" panel. Specifically:

Authorization: If a user has already selected a security scheme and provided credentials/tokens, these should remain active when switching between resources of the same API.

Common Headers: Standard headers (e.g., Content-Type, Accept, or custom tracking IDs) should be preserved if they are applicable to the new resource.

Smart Refresh: Instead of a destructive refresh of the entire frame, only the fields specific to the new resource (path parameters and request body) should be updated.

Business Value / Justification:

Improved Developer Experience (DX): Developers often test a sequence of calls (e.g., POST to create, GET to verify). Re-entering authorization and headers for every single call is repetitive and frustrating.

Efficiency: Reduces the time spent on manual data entry during the API integration phase.

Lower Barrier to Entry: A more seamless "Try-it" experience aligns the IBM Developer Portal with modern industry standards seen in tools like Postman or Swagger UI, where session state is often maintained.