Design /api/v3 for NuGet's clients such that OData isn't needed for our own client requests #595

Closed
jeffhandley opened this Issue Sep 12, 2012 · 8 comments

Projects

None yet

5 participants

@jeffhandley
Member

No description provided.

@maartenba
Contributor

Anything we can help with on this one?

@ghost
ghost commented Nov 27, 2012

We're working on this.

@jeffhandley
Member

@maartenba I'd love to hear details from MyGet for what API calls you guys make, what feels hacky, and what you'd like to be able to do.

@maartenba
Contributor

We're doing a couple of calls related to searching (basically OData filtering because search is too limited). The "hacky" part is mainly the fact that we have to use the methods like Search() to be sure of having an indexed and fast result.

Also having pure JSON results instead of bulky ATOM would be great. It's a bandwidth hog to use XML.

What I'm interested in is reviewing the API ideas you are thinking of for v3 and see how they will land in 3rd party products like MyGet.

@ghost
ghost commented Nov 27, 2012

You can have the service return JSON by setting the Accept header to application/json. You have to parse it manually though, because the WCF data client doesn't support JSON. But I heard the latest version of WCF data service client does support JSON (although I haven't tried it yet)

@maartenba
Contributor

Thanks Luan! What would be your reason for moving to API v3 by the way? Trying to find out what the reasoning is and what options we would like to see for interacting/integrating.

@howarddierking
Contributor

@maartenba check out https://github.com/howarddierking/NuGetGallery/wiki/Api-v3-Overview - this is a brain dump of some brainstorming plus some of my early thoughts on API v3 capabilities...

@jeffhandley
Member

My motivation, @maartenba, is that I don't want to have multiple layers of abstraction sitting in between specialized client/server calls. I want us to be able to control thing like, "When the user opens Manage NuGet Packages, the results should be A) cached, and B) FAST." Having OData sitting in the middle makes it hard to do that.

I just felt more and more like funneling all requests through a single endpoint was making it hard to yield good and fast results for all. Kind of like the "We didn't design a phone for all of us, we designed a phone for each of us" mentality.

@maartenba
Contributor

That is exactly my thought: we currently have to know about your implementation (Lucene indexed or not) to achieve best results.

Regarding https://github.com/howarddierking/NuGetGallery/wiki/Api-v3-Overview, I like the list of services at the bottom. Those should work for most of our needs, the important one is "search" which should be as flexible as possible. Another important one should be including "related" services such as SymbolSource URLs in result data.

@ferventcoder
Contributor

Reading over the list, I see some really good improvements (with the list of services). I definitely like the idea of following packages and having a feed to subscribe to.

One thing I noticed was Edit User Profile. Are you planning on expanding the user profile? Right now it is severely limited (email / receive notifications). Kind of curious where you are planning on taking it.

A couple of things that I have been thinking about with chocolatey are having the ability to mark a package as outdated and also mark a package as bad in addition to reporting abuse.

Outdated - when a certain number of folks mark the package outdated, it shows on the gallery as possibly outdated.
chocolatey/chocolatey.org#12

Bad - This one is similar to reporting abuse, but it's not that the package is abusive, it just has some issues for some reason or another. After a certain number of marks, this would also mark the package on the gallery.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment