How to do GET /api/v1/package/{PURL}?

[carlosthe19916]

• If I fetch data from GET /api/v1/sbom/{key}/packages then I get the following response:

{
    "items": [
        {
            "id": "SPDXRef-008baaa8-8056-48c3-b019-24a82b3a4bf1",
            "name": "quarkus-smallrye-metrics",
            "purl": [
                "pkg://maven/io.quarkus/quarkus-smallrye-metrics@2.13.8.Final-redhat-00004?repository_url=https://maven.repository.redhat.com/ga/&type=jar"
            ]
        }
    ],
    "total": 880
}

• Each Purl is currently decomposed in the UI and then rendered in a table, like the image below:

• Here is the question. How can I use a single PURL and use it in GET /api/v1/package/{PURL}? currently in order to fetch a single package I need the uuid of a package, but in the example above all I have is a PURL

[ctron]

I totally understand the confusion. I don't have an answer, but I can explain it.

The {id} (what you have as {key}), is actually the UUID of the SBOM. That returns "packages", which used to be PURLs, but today are actual SBOM packages/components. These have again an ID and may (or may not) have multiple CPEs and PURLs.

The ID of the package in this case is SPDXRef-008baaa8-8056-48c3-b019-24a82b3a4bf1. You can use this to fetch additional relationships, in the context of the SBOM. It is a "package/component of the SBOM" (SPDX: package, cyclonedx: component).

The /api/v1/packages endpoints target "PURLs", which used to be known as "packages". However, to me, PURLs are identifiers for packages. CPEs and hashes are other types of identifiers for packages.

If you want to learn more about "packages" (not in the context of an SBOM), then you can use those endpoints (from /api/v1/packages). There you have endpoints like:

• /v1/package/type/{type}/{namespace_and_name:[^@]+}
• /v1/package/type/{type}/{namespace_and_name:[^@]+}@{version}

There are also APIs which allow you to get information for those "packages" (actually PURLs) by their internal ID. The internal ID (which is a UUID) can actually be derived from the PURL. But I would NOT (!!) recommend to do that. I see this as an implementation detail that no one should build upon.

What might make sense is to either expose this UUID through the "SBOM package" struct. An I think I saw some places where that already happened. And to amend /api/v1/package scope APIs to accept either a UUID or an actual PURL.

It might also be good to consider renaming the /api/v1/package scope to something different. Something that reflects that this is about PURLs. Not packages.