For example, POSTing to the recent /api/upgrades_info/graph-data tarball endpoint with a JSON payload requesting the inclusion of signatures for given releases:

{
  "signatures": [
    "sha256:750fe7239f8633662899a68a1204f57b7ea92189ea8024ed18d9948d1fed00b6",
    "sha256:bdc145f7f6347433f8461a1133d6354abf52268925ce7459a4294d44b9beb4ef",
    "sha256:5e8f403a14eed840b01434115300f2e68cd1232aa47f9509433a46341da2f2b8"
  ]
}

will return a tarball response containing a filesystem like:

$ tree signatures
signatures
└── sha256
    ├── 5e8f403a14eed840b01434115300f2e68cd1232aa47f9509433a46341da2f2b8
    │   └── signature-1
    ├── 750fe7239f8633662899a68a1204f57b7ea92189ea8024ed18d9948d1fed00b6
    │   └── signature-1
    └── bdc145f7f6347433f8461a1133d6354abf52268925ce7459a4294d44b9beb4ef
        └── signature-1

4 directories, 3 files

All of the following are negotiable:

• Whether we want JSON POST to be the client-side request.
• The format of POSTed JSON, if we do decide to POST JSON.
• The filesystem structure of any included signatures, e.g. if we want 5e/8f40... or other sharding to avoid including "too many" entries in a single directory, for requests that ask for lots of signatures.
• Whether we want limits on the number of signatures that can be included in a request.
• How we respond if some or all of the requested signatures are not available.