About the REST choice of implementation
Here is the thought process:
=> We don't want to have a workflow_state because of inconsistency plus the fact that it is yet another thing to read
=> We want to recompute permissions on the fly instead so that it's clear what you can or can't do
=> We can't on a Tracker level because a tracker has no Artifact context
=> We could add a parameter to the /trackers/:id route to pass a changeset id because those permissions do rely on the changeset itself (state)
=> This is akward, as the /trackers/:id is really about structure
=> We add it to the /artifacts/:id because there, there is the artifact and changeset context
Overall, the idea is that wether we put it in /trackers or /artifacts, we blend the routes: Either /trackers becomes changeset aware, or /artifacts becomes structure aware. We went for the second solution for three reasons mainly:
Those new workflow post-actions (hidden/read-only) are a new paradigm. The old structure vs values way does not work anymore in this context as structure is now dependent on values. We thought the second solution was the easiest to deal with for a futur "us" who will add more of those things. We first wanted to make it default (no `tracker_structure_format` parameter), but as it is querying more informations and thus might be a bit slower, we went for protecting it behind this parameter. (We benchmarked the difference leading us to this decision).
If we make a parallel with the web UI, the tracker defines the structure of an artifact, but what does an artifact really look like is dependend on the artifact, you only discover it when you open the artifact page. Moreover, this is going to be even more true as we move in this read-only/frozen fields and hidden fieldsets direction, both dependent on the workflow's current state.
If we put it in the /trackers route, when you want to know what you can or can't submit and what you can or can't show (in the case of hidden fieldsets), you need to query the artifact, then you need to query for it's changesets, then you need to query the /trackers with the parameter of the changeset you want to get the structure in a changeset awaare way.