tl;dr: introduce "functionality sets" that can be associated with REST modules. Other tasks will build on these. In short, functionality sets are groups of behaviors that can be mapped to audience designations. See the parent task for context.

Initial Audience Designations

The following audience designations are currently available:

• public (indicated in the path by absence of any specific designation)
• beta

Others designations are planned. One of these ("internal") will be implemented in a followup task under the same parent task.

Required Functionality Sets

The following functionality sets should be implemented as part of this task:

• disabled (endpoints are not available to be called, spec is not viewable or discoverable, no sandbox entry)
• hidden (endpoints are callable but spec is not accessible or listed in /discovery, no sandbox entry)
  • spec should still be available within tests, so that things like response schemas can be used to validate endpoint behavior
• discoverable (endpoints are callable, spec is listed in /discovery, no sandbox entry)
• opt-in: (endpoints are callable, spec is listed in /discovery, opt-in to view on sandbox)
  • there will be multiple opt-in groups. See below for details.
• published (endpoints are callable, spec is listed in /discovery, sandbox entry)

Layering

Because audience designations are new and we're still learning exactly how they'll work, we should avoid tightly tying any particular designation to any particular behavior. A layer in the code should translate the behaviors of designations to functionalities. Audience designations should be mapped to the various types of functionality in a way that lets us easily make adjustments.

This mapping could be hard-coded, and may involve creation of constants for each audience designation and each functionality set.

This mapping could live in the existing ModuleManager class, or in a new related class.

Opt-in

(TBD)

Notes

Initially, all audience designations should map to the "discoverable" functionality set. This will avoid inadvertently affecting existing production behavior. Subsequent changes will adjust the mapping, once we're ready for it.

The task author is using the term "functionality set" as a convenient way to talk about these groups of related functionality. That term might or might not be useful in code. If not, there's no need to include it. If the implementing engineer needs a term but comes up with a better one, feel free to use that instead.

There should be no visible production impact on REST module behavior from any of these changes. Visible changes will happen in followup tasks.