JSON Script API

[sizzlemctwizzle]

The API would behave similarly to script lists (with sorting, pagination, searching, etc.) but return a JSON array of script attributes instead of an HTML page. The full specification needs some thought and discussion.

[jerone]

+1

[jerone]

There's a new addon available called "Greasy Script" that, just like previous Greasefire, allows you to search for user scripts available for the site you're just visiting. A good addition to that addon would be to support searching scripts on OUJS. Are there any plans, besides this issue, to open up (search) API's?

[sizzlemctwizzle]

Are there any plans, besides this issue, to open up (search) API's?

Atm this is the all encompassing JSON API issue. Besides I did say:

(with sorting, pagination, searching, etc.)

[Martii]

Duped from Ede123/greasy-scripts#6 (comment)

Hi Mike, thanks for interest!

The current idea is to give the user script results per domain - a "domain" consisting of a public suffix plus one domain name part. (If you're familiar with Firefox programming: Greasy Scripts uses nsIEffectiveTLDService.getBaseDomain() to extract the domain from any given URL).

Therefore an API that allows to search for scripts by domain name using exactly this definition of "domain" would be the most compatible approach.

After a quick check I'm afraid your normal search wouldn't return useful results in all cases. For example a search for https://openuserjs.org/?q=mozilla.org returns a huge list of scripts - few of them actually being applied to mozilla.org.

If you create a new API for this it would probably suffice if you did a quick (domain-based) check of @include / @match. There's no need for advanced checking (like subdomains, exludes or even paths). As a rule of thumb: If a script is applied to any URL belonging to a certain domain (with above definition) or subdomains thereof it should be found when searching for that domain.
Regarding specific implementation

Greasy Scripts currently supports the Greasy Fork API, so the more alike a future OUJS API will be, the easier the implementation of current and future features across both projects (and that is not only for Greasy Scripts but for any code that might be written for any of the projects). So as far as you find their approach useful you might want to consider re-using syntax and data structure wherever it makes sense.

As an example Greasy Scripts currently makes use of the following Greasy Fork API calls / URLs:

1. https://greasyfork.org/en/scripts/by-site/mozilla.org.json?meta=1 - this is the current core of it all: a quick way to determine the number of scripts that are available for e.g. mozilla.org. Kudos to @JasonBarnabe for implementing this for me!
2. https://greasyfork.org/en/scripts/by-site/mozilla.org.json - this would be the according API call to get details on each of these scripts (Greasy Scripts does not currently use it but if I ever implement anything to provide the user with more information about the available scripts, this is what I'm going to use)
3. https://greasyfork.org/en/scripts/by-site/mozilla.org - this is the current landing page a user will see if he decides to view details on the available scripts.

As you see (at least for now) it would be completely sufficient if OUJS offered 1. and 3.
At some point I might think about collecting available scripts in a native GUI (then I'll need 2.) but there's no pressing need for it as long as all supported projects have a nice landing page.

---

And of course my reply of:

I believe that we can always add a QSP for a more finite search result... we search by default a bunch of intel on the script lists. As far as the API itself goes we can return a collection in just about any ordering and tier structure. Thanks for the linkage and explanation.

[NatoBoram]

An API would be very useful for #1755 and badges/shields#5505!

[ghost]

I'd like to deploy my script via CLI like npm git heroku.
Something like https://github.com/isaacs/gist-cli/tree/v0.2.3 would suit my needs :)