Ability to list/query packages

[markhalliwell]

This is two-fold.

1. Before, it was possible to get all the versions and assets in a single query. Now, I have to do a single query to get just the versions and then from that, do multiple requests to get each version's assets. This isn't really ideal from an API consumption standpoint because that means instead of making a single request, I'm now making dozens. Yes, I did see Trying to get a list of files using the API will result in a 403 response. on the project page, but it offers no reasonable explanation for why this is, especially considering that this was a feature of the previous API this one is supposed to supersede.

2. Before, it was possible to query multiple packages based on wildcards. This was primarily useful for inline UI discovery and installation for a CMS. AFAICT, there is currently no replacement functionality of any kind offered. I understand this is a new structure and, likely for performance reasons, some functionality is limited. However, isn't it possible to perhaps get around this by introducing more query string options?

[MartinKolarik]

Getting a list of files for all versions, indeed, is not supported. The are many reasons for that, but what's probably most important, it can actually improve performance - because each response contains data only for one version, it never changes, so we are able to cache those responses on a CDN permanently, making everything a lot faster.

If you need a list for all versions (which is a rare requirement, btw), it's still fairly easy to do, and you are able to implement better caching as well - after the initial fetch, you just keep updating the list of versions, and then only fetch a list of files when a new version appears. Of course, if performance is not a priority, you can just make all the queries all the time.

Trying to get a list of files using the API will result in a 403 response.

That is related to the previous sentence: Neither jsDelivr CDN nor this API supports packages larger than 50 MB.

It only applies to those packages.

[MartinKolarik]

As for the second question, there's no search API because we now simply serve everything from npm, and there already are existing search APIs for it:

• Searching jsdelivr.com for a package #6
• https://api-docs.npms.io/
• possibly other

[MartinKolarik]

@MarkCarver let me know if you have any other questions.

[markhalliwell]

Sorry for the late reply. I've been inundated with client work.

It's unfortunate that this API cannot provide endpoints that somehow mimic what was provided in the previous API. It may not be as "performant" as the primary endpoints, but it would certainly be useful.

Even providing an endpoint to search by "wrapping" a solution mentioned in #7 (comment) would be fairly easy enough on your end I would think, especially considering you already have the infra in place.

This new API makes upgrading very difficult because the current implementation in https://www.drupal.org/project/bootstrap will have to be completely rewritten to make multiple requests: https://www.drupal.org/project/bootstrap/issues/2657138#comment-12422694.

I'm not saying that it's not my responsibility to do the necessary work on my end and understand that this is technically a new API. Just sad that there is little to no migration path for an API I just realized became deprecated.

[markhalliwell]

FTR, I did see https://github.com/jsdelivr/data.jsdelivr.com#let-us-know-how-you-use-this-api and will be making changes in https://www.drupal.org/project/bootstrap/issues/2657138#comment-12422694 so that it sends a more appropriate User-Agent header.

[MartinKolarik]

I understand that migrating to this API will require some changes in your's (and everyone else's) code but there was no way to keep it backward compatible. It was supported for four years, and the new one will most likely be supported even longer.

Because backward compatibility isn't possible anyway, I prefer to keep the new version simple and easier to maintain. I think the new endpoints are still very close to the old ones and adding one loop to send some additional requests should be fairly easy.

Adding a search endpoint is not as easy as it seems, and even though I understand it might be a little easier for devs to use 1 API instead of 2, I don't see it as a priority right now. I really recommend checking out Algolia, they have great SDKs for almost any language and much more features than we could possibly provide.