Arvados

Suggest adding virtual fields container_state and container_exit_code which have the value of the corresponding fields of the record with container_uuid, or null if no container is assigned.

Alternately, we could add a query parameter which specifies that we want the entire container record embedded in the response.

IMO, these aren't container_request fields so they shouldn't appear as container_request fields.

Suggest we support an "include container record" flag in container_requests#index and #show requests, and return the whole container record.

Since we're not (yet?) using jsonapi, we need to choose a response format for this. We should use something that can extend to other similar situations, like "include created_by_user record".

http://jsonapi.org/format/#fetching-includes

Just one thought, we have wandered a little bit from the original goal of making the API easier for getting container status from container_request. Returing a separate "includes" section takes a similar amount of Python code to interpret as the current approach that requires making a second API call. Embedding the record in each item so that one can can write items⁰[container][state] is much simpler for the user (ie Bryan).

That said, "includes" is a more general solution that is better suited for other use cases like optimizing Workbench queries and so probably still the one we go with.

Perhaps the client library could offer a "join response items" convenience function that assigns includes[x] to items[y][f] for all items[y][f+'_uuid']==includes[x]['uuid']...?

Again speaking privately here. This seems important. Workbenches are slow because of small API issues like this one. [uuid, in, [...]] filter to retrieve corresponding containers seems always a bit on the slow side. Thank you in advance.