|
|
APIs for getting user/script info: Formats: XML, JSON, JSONP if an optional callback is specified. Parameters: user_id or script_id (depending on call) To get a list of a users' scripts: http://api.userscripts.org/v0/users/:user_id/s... To get a list of a users' favorite scripts: http://api.userscripts.org/v0/users/:user_id/... To get the details (versions/update times/...) about a script: http://api.userscripts.org/v0/scripts/:script_i... So to get a list of my scripts the call would be: http://api.userscripts.org/v0/users/2/scripts.xml If I wanted that list in json with a callback Badge.update I would call: http://api.userscripts.org/v0/users/2/scripts.j... Which would return:
None of this has been implemented, but perhaps will be soon. The url schemes are v0 since they aren't guaranteed to exist, v1 will be the first real version. |
|
|
As great as XML and JSON are, what I'd really like is a URL that will return a single script's entire ==UserScript== block in plain text, exactly as it exists in the script, and nothing more. Greasemonkey already has a parsing routine for this format (which I, for one, was encouraged by the dev team to borrow), so why should people have to reinvent the wheel? |
|
|
ScroogeMcPump: Append "?" to the script installation URL, and you get exactly that, without any update of the script installation counter. Also: woot! :-D *looks forward to seeing the domain propagate to name servers* |
|
|
@ScroogeMcPump, Sorry for the delay - I've exposed it here: http://userscripts.org/scripts/meta/29181 This method is NOT cached yet as I'm pretty sure that isn't a good url for it. So please don't integrate the call into any update code yet. Lets flesh out what the url should be and then I'll add caching. |
|
|
To Johan Sundström: !WFM - I get the full script, served with "Content-Type: text/javascript" (meaning "Would you like to save this file?" is invoked) - but it does seem to inhibit installed++. To Jesse Andrews: Perfect! As for "what the url should be", I have nothing on which to base a reasoned opinion, so I'll leave it to you. |
|
|
Scrooge: Yep; I somehow missed the whole part about filtering away all the non-header portions of the script. |
|
|
Then you kinda missed the whole thing. ;-D And in case someone else (cough) missed it: How long will it take before api.us.o stops giving "Server not found" errors? It'd be nice to see what else is in the works. |
|
|
Regarding the API, it is still in progress: None of this has been implemented, but perhaps will be soon. The url schemes are v0 since they aren't guaranteed to exist, v1 will be the first real version. Regarding the url for meta information - is there a url that would be easier for script authors to get to via introspection? If not I'll design it for the best/easiest caching requirements. |
|
|
ScroogeMcPump, http://userscripts.org/scripts/source/29181.met... now exists and is cached. (it works for all scripts that have a proper header) |
|
|
I liked it better when it was served as text/plain instead of text/javascript, since downloading it as a script will, by definition, create a "do nothing" file - but since I (at least) expect only to access this URL via XHR, I guess it doesn't matter that much. |
|
|
I'm going to leave it JS since currently it is serving from the filesystem (it gets recreated after each upload) and without changing the filename changing the mime-type will be complicated (I think). |
|
|
Any news on that API Jesse? api.userscripts.org seems to be offline. It would be useful for my US.o script author helper script, so I don't have to parse HTML to get the information, deal with pagination, etc... |
|
|
Any answer? I would like to know about this before beginning to update the parser code of the script |
![]() ![]() |
Has the API moved to some other address or is it completely offline? It would be very nice to be able to use the API instead of parsing HTML. |

