Can the official provide an interface（web api) to query the latest package information

[cheapw]

Can the official provide an interface（web api) to query the latest package information, then we can use the package info to build windows desktop Gui app to manager our software base on winget commands, that may be user friendly. If we could get the available package info easily, we can do a lot of amazing things.

[latere-a-latere]

Something like this? microsoft/winget-cli#118

[SoftCreatR]

It's pretty easy. I'm doing this on https://www.winget.it for example. All you have to do is to query the GitHub API twice:

1. https://api.github.com/repos/microsoft/winget-pkgs/git/trees/master

Here, you need to fetch the SHA hash for the path manifests.

2. https://api.github.com/repos/microsoft/winget-pkgs/git/trees/XXXXXX?recursive=1

Replace XXXXXX with the SHA hash you've got from the 1st request.

--

That's all. You can now extract publisher, name and version from all paths of type blob.

[SoftCreatR]

Alternatively (but not guaranteed to exist forever) you can use our cached package list, which is being refreshed every few minutes: https://www.winget.it/packages.json

[cheapw]

Something like this? microsoft/winget-cli#118

Something like this? microsoft/winget-cli#118

Yes, that's a good idea

[SoftCreatR]

@cheapw Well, do you really want to wait until there's something from M$? I mean... The approach explained above should already fit your needs.

[cheapw]

Alternatively (but not guaranteed to exist forever) you can use our cached package list, which is being refreshed every few minutes: https://www.winget.it/packages.json

It's pretty easy. I'm doing this on https://www.winget.it for example. All you have to do is to query the GitHub API twice:

1. https://api.github.com/repos/microsoft/winget-pkgs/git/trees/master

Here, you need to fetch the SHA hash for the path manifests.

1. https://api.github.com/repos/microsoft/winget-pkgs/git/trees/XXXXXX?recursive=1

Replace XXXXXX with the SHA hash you've got from the 1st request.

--

That's all. You can now extract publisher, name and version from all paths of type blob.

Thanks! But query the github api directly may come across GitHub API limit with the increasing number of api request. It may need some backend cache mechanism, just like thist url (https://www.winget.it/packages.json)

[cheapw]

@cheapw Well, do you really want to wait until there's something from M$? I mean... The approach explained above should already fit your needs.

No, I just want to write a personal app base on the winget-cli, not so urgent, I will keep an eye on the progress of this project, I will glad to see any new features and progress.

[SoftCreatR]

It may need some backend cache mechanism, just like thist url (https://www.winget.it/packages.json)

The API is limited to 5k requests per hour, so generating/hosting your own (prepared) JSON might be a good idea.

[cheapw]

The API is limited to 5k requests per hour, so generating/hosting your own (prepared) JSON might be a good idea.

Thanks, I will give it a try !

[SoftCreatR]

As shown on https://www.winget.it, performing these two API requests (and cache their response, at least for 5 minutes) already provides nearly all informations you need. The only thing that is missing is the manifest data itself. However, (when needed) i would request them (without using the GH API) on demand and cache them too.

[cheapw]

Yes, we can just use app's Id to install the app, and the version Field is to judge whether a new version is available based on the already cached version.

[SoftCreatR]

FYI: I've rewritten the process that creates the package.json. The file now contains all manifest contents for maximum flexibility. Just in case, that anyone wants to use it: https://www.winget.it/packages.json

[SoftCreatR]

Here's another (more official) way: Download the signed MSIX package from the source server: https://winget.azureedge.net/cache/source.msix

This file contains an SQLite database, located in source.msix/Public/index.db. This SQLite database contains all required informations about manifests. It will be rebuilt upon merges in this repository, so whenever a change happens, this file should cover it.

Then, instead of downloading single manifest files using the GitHub API, download it from the source server, e.g. https://winget.azureedge.net/cache/manifests/AnsgarBecker/HeidiSQL/eca9-11.0.0.5919.yaml

To make sure, that you always use the latest, cached version and to prevent downloading the same database over and over again, perform a HEAD request against the msix file linked above and save either the Etag, or the Last-Modified timestamp from the response header.

Good luck :)

[denelon]

When we finish the REST API work, we do expect to have an instance available with all of the packages from this repository.

[dominikgeimer]

When we finish the REST API work, we do expect to have an instance available with all of the packages from this repository.

Any update about the status?

[denelon]

We are building the REST API, and will provide reference documentation. Until the manifest changes for 1.0 are implemented, we will hold off on building a RESTful instance of the community package repository/source.

[yoshiask]

We are building the REST API, and will provide reference documentation. Until the manifest changes for 1.0 are implemented, we will hold off on building a RESTful instance of the community package repository/source.

It's been quite a while, are there any updates on this?

[denelon]

You can follow along at https://github.com/microsoft/winget-cli-restsource to see changes being made. We are standing up the infrastructure. Next steps include taking the output from the Windows Package Manager Community Repository here and passing merged manifests to the REST source.

[Trenly]

@denelon - Can the team provide an update on the progress here?

[denelon]

We've got an instance up and running. We're working through some of the publishing challenges. We're not ready to offer any SLA guarantees so we've decided not to "officially" share the URL until the decision regarding support has been made. There has also been some discussion around the differences in the UI/UX with the WinGet client when hitting a REST source. We've also been discussing what it would look like to have the PreIndexed package and the REST source able to logically back each other up in the event of an outage (similar to what happened with the CDN problems we've recently encountered).