Not sure how to retrieve platform information from a schema2.DeserializedManifest. Working on figuring this out.

This part is a little unclear based on the backed.GetRepository function as it is right now. Maybe it should be possible for it to just take a reference.Named object instead of reference.NamedTagged, since it doesn't seem to depend on having the latter.

why is it a post ?

I made it POST because we needed to send registry auth token for private repos. But since we send it in the header instead of the payload, is GET fine?

I believe GET is fine

@vieux changed it to GET.

+1 on the GET

What about returning the top-level manifest itself instead of (or in addition to) the digest? I could imagine this being useful for some things.

We could also return an optional config blob if one is referenced by the top-level manifest.

Then the platform determination could be done on the client side, making this /manifest more generic.

It's still not really ideal, because the daemon is deciding what items to fetch from the registry and return to the client. I kind of like the idea of proxying the registry API through the daemon, but that's a pretty big project and probably way out of scope for what we're trying to do here.

That said, I don't feel strongly about any of this, and I could be okay with just returning specific fields such as Platforms in the API response if that's what people prefer.

@aaronlehmann I'm inclined towards making it as general as possible. So returning the top-level manifest (and config blob) sounds like a better idea, especially because then the client can deal with it as it likes.

Also, then any format updates have to be dealt with by the client only.

@aaronlehmann as an example, what do you think about

{
  Digest       digest.Digest,
  Manifest     distribution.Manifest,
  ConfigJSON   []bytes,
}

I still think we'd have to separate cases (fat, v2, v1 manifests) to get the right config blob, but then the client could Unmarshal it as desired.

Yeah, that's basically what I had in mind. Although maybe Manifest should be []byte so that we aren't introducing distribution types into the API, and also so that the digest can be verified. It's ugly to put JSON inside JSON though.

Do you mean marshaling the manifest into []byte before sending? I have a couple of questions

• Why does the digest need to be verified at the client?
• Why does sending []bytes help with it?

It's ugly to put JSON inside JSON though

This applies to ConfigJSON as well, right?

The manifest is a JSON document. DeserializedManifest is just a convenience for working with it in Go code. If you marshal it to JSON, you'll get the same set of bytes back, so the hash won't change (DeserializedManifest implements a MarshalJSON method that ensures this).

However, I've thought about it some more, and I don't think using []byte is worth the ugliness. Let's do this instead:

{
  Digest       digest.Digest
  Manifest     *json.RawMessage
  ConfigJSON   *json.RawMessage
}

Manifest would contain the original manifest JSON returned by (*DeserializedManifest).MarshalJSON. This is similar to using []byte, but it causes the JSON to be inserted directly instead of as a string. We lose the ability to verify the digest (because of possible whitespace added around the value during the marshalling process), but we avoid the ugliness off putting JSON inside a string inside JSON.

Why does the digest need to be verified at the client?

I don't think there's an immediate reason to verify the digest at the client, but I was thinking that if we're going to send the manifest to the client, we might as well send the exact manifest.

Why does sending []bytes help with it?

Because the hash is computed over these bytes.

It's ugly to put JSON inside JSON though

This applies to ConfigJSON as well, right?

Yes.

@aaronlehmann PTAL, does this look reasonable?

Presumably this should return an error

non-blocking: it might be slightly more readable to use a type switch here. It's purely a cosmetic suggestion, though.

I guess since we're potentially returning different kinds of manifests in this field (schema1, schema2, manifest list...), we should have another field containing the media type. Depending which kind of manifest is being returned, this field would either be set to schema1.MediaTypeSignedManifest, schema2.MediaTypeManifest, or manifestlist.MediaTypeManifestList.

Ah, I intended to add this but missed it. Doing it now.

Maybe ManifestMediaType?

I suggest adding the omitempty flag, as this field won't always be present.

Let's move the lines related to ConfigJSON into the *schema2.DeserializedManifest case so that manifestInspect.ConfigJSON remains nil when other types of manifests are returned.

@aaronlehmann I wasn't sure if there was a ConfigJSON we could return for FAT manifests, so I put it here. It doesn't seem to be the case, so I'll move this.

Check for an error

Perhaps we should add an example response here, because the current output doesn't provide a lot of information to the reader 😄

@thaJeztah updated. PTAL.

Looks like empty array definitions are still causing an error, I'm fixing those.

Can we come up with some sample URL's and/or fill the OSVersion / Variants? Or do you think it's ok to keep them empty?

@thaJeztah In the examples I saw, these weren't filled, so I think it's okay. I can try to search for better examples later.

Wondered if this should be an uint64, but I see it's coming from an existing type