689800 - inventory: be consistent and explicit about handling of sub-tables in API

Status: RESOLVED WONTFIX

(Infrastructure & Operations :: Infrastructure: Tools, task)

Description

[Dustin J. Mitchell [:dustin] (he/him)]

I think there are two ways to go with this:

 1. API uses ID's everywhere, and users are responsible for fetching the ID's in advance if they need them.  In this case, we should probably have a download-the-whole-list command (e.g., GET /v2/allocations) to make caching easy.  The downside is, if you choose to move some existing value into a sub-table later, you'll need to either fake it or change the API.

 2. Denormalize the values for input and output, so the API specifies e.g., allocations by name.  You've already noted a problem with system_rack, since it has a sub-sub-table, and doesn't have a unique name.

I don't think we should try to hybridize things -- for example, if we try to "guess" whether an allocation is an ID or an allocation name, then we preclude allocation IDs that look like numbers.

It probably *does* make sense to "denormalize" results returned to the user -- so, for example, a GET of a system should return both its allocation_id and allocation.

If there are cases where there's a need to look things up by name, that should be handled explicitly in the API.

Anyway, let's start by being consistent, and sand off the rough edges from there.

Comment 1

[Ludovic Hirlimann [:Usul]]

Is this still true ?