Provide public Gallery API

[joaomoreno]

It would be great if this library would provide an API to access the Marketplace Gallery in a public way.

vsce, the VS Code's extension packaging tool, now implements a version of this.

[stephenmichaelf]

@joaomoreno Is this what you're looking for? It has the ability to work with extensions like the code you referenced.

[joaomoreno]

No, I mean the public API. That's the private one. VSCE uses that one extensively already.

[stephenmichaelf]

@joaomoreno I saw the issue that referenced this above, 238, was closed on your end. This may still be an issue we have. We have had several other customers update to the latest version of this library and none of them are having issues.

The HttpClient used in this library comes from our typed-rest-client, it doesn't live in this library. Could you describe how you are using it a bit more so I can try to find out if/where there is a problem? Thanks!

[joaomoreno]

The current version of vsts-node-api doesn't expose public extension querying. All REST methods require authentication. Did I get this wrong?

So, we created our own methods for querying publicly: https://github.com/Microsoft/vscode-vsce/blob/master/src/publicgalleryapi.ts#L1 This is a hack, which stopped working in the latest vsts-node-api.

This issue refers to exposing that public API, so we don't do the hack.

[raix]

It's correct that the getGalleryAPI requires auth - thats why we use the HttpClient (moved to a separate package "typed-rest-client" in final release of the node-api == breaking the "hack")

We could update vsce to use the typed-rest-client but it might break again in the future?

I'm not sure how the public api access is implemented in vs code "extension search" etc. (same endpoint though)

[stephenmichaelf]

Thanks for the clarification.

@joaomoreno Yes authentication is required.

My recommendation would be to change to the typed-rest-client. If by break you mean get moved to a new repo, that is unlikely as the sole purpose of the library is now to be a rest/http client. Single responsibility.

@bryanmacfarlane Does that make sense to you too?

[raix]

@stephenmichaelf All dependencies are vsts-node-api internals https://github.com/Microsoft/vscode-vsce/blob/master/src/publicgalleryapi.ts#L1-L5 so really tight coupled (not to mention api versions/endpoint details).

I could help make a pr if you want - the footprint would be around 50 lines

(reference to similar code in vs code)

[damccorm]

Looks like this should be fixed by #233

[raix]

@damccorm we need to use the public Gallery api (public == no need to set auth handler)

[damccorm]

Ah, gotcha, thanks for clarifying.

Upon investigation, it looks like the thing that is holding the library back from this currently is the call in every method to vsoClient.getVersioningData, which eventually triggers a call to the rest client which returns a promise of a VssApiResourceLocationLookup object. This object contains information used to construct a ApiResourceLocation object which has all the information we need to construct the appropriate request, including the routeTemplate and versioning info. Without this information, we can't construct the request. I see several possible options for addressing this:

1. Find a non-authenticated alternative to the current rest call which returns a VssApiResourceLocationLookup object. This would be ideal, but I don't think that endpoint exists.

2. Have users manually pass in the entire request URL. This would work, but also isn't very helpful - I think at this point we might as well just instruct people to use the typed-rest-client and create their own requests. This solution isn't really in line with the rest of what this library does and is probably out of the scope of what we are trying to do.

3. Write these functions ourselves and manually code in the key pieces we need (e.g. route template, versioning info). It seems like that is basically what vsce is doing, combined with a little bit of option 2. While this is helpful in certain cases, this goes against one of the core ideas of this library, which is decoupling the updating of this client from changes in the REST API. When the API is changed, we're able to just regenerate, push here, and all of that functionality is exposed with minimized risk of bugs. This option would remove that decoupling and require manual updates as the APIs change, creating a higher chance of bugs and unexposed functionality.

4. Do nothing/recommend that users create and send their own requests using typed-rest-client. I lean towards this option.

I'm open to other options other than what I've listed here, but I think as of now I'd lean towards sticking with option 4 and avoiding non-generated APIs here.