API functions

[yoav.ost]

Hi,

I'm a developer and i'm doing an extensive use in you'r API, the WebUI that is.

I have a few requests so it would be easier to work with the API.

1. A standard function that would return (in JSON of course) a list of all actions, list and get methods + syntax.

2. When getting a list such as in list=1 or getfiles or any other it would be cool if the reply would be like in getprops. For example list=1 in "torrents" I would have "hash" : hash_code and not just the value.

It would make the work much easier for delevlopers to serialize the results so we wouldn't have to change the serializing every time you change the result format.

3. I'm using version 3.0 and WebUI 0.38 and noticed that you added the RSS in list=1. Are there any new actions that can be done with rsses? Where can I find some documentation?

Regardless, I think the RSS list should be in list=2, it would be cool to have more lists and in this way, I, as a developer, don't have to make any changes in list=1, but just add list=2 if I want to.

4. After adding a torrent (by URL or file) it would be very cool if in the reply I would get the hash code of the new torrent. For future reference.

5. Right now I can do 8 actions (start, stop, pause, forcestart, unpause, recheck, remove, remove data) on a given torrent using it's hash code.

- I would like to suggest 2 more: move up and down in queue.

- After doing the action a reply would be nice. If it were successful I would like the new details of the torrent and if not (invalid hash code or something) a message that indicates the problem.

6. Working with labels:

- An action that adds a label.

- An action that assigns a label to a torrent (if it's a new one it creates it also).

I know i'm asking for a lot, but I think it would really help developers in the future.

I would like to pay your attention to the fact that i'm not asking for anything new, It can all be done using the windows GUI.

Thank you very much,

Yoav

[yoav.ost]

Hi,

After reading the WEB UI API post on the Web API forum I got answers for 5 and 6.

So basically what i'm asking for is just a small change in the returned JSON's

- For actions a reply about the torrent changed (or added).

- For lists (or arrays) using "hash" : hash_code format and not just an array of values.

Hope you would understand and include my changes in the next version of WebUI.

Thanks, Yoav.

[yoav.ost]

Why am I being ignored? Can someone please answer me if what i'm asking is possible?

[Firon]

This isn't the right subforum to ask.

[yoav.ost]

Please move this thread to the Web API forum.

Thanks.

[Ultima]

1. What's wrong with the existing docs? I see absolutely no reason why docs need to be duplicated as something built into the API.

2. I've already previously suggested this, but in retrospect, decided it wasn't worth the change. It isn't necessarily better if you aren't requesting data specifically by hash, because in the end you still have to loop through everything. A deserialized JSON map/dictionary has no idea how many items it has; you'd have to loop through everything to get the count too, whereas in an array, it's immediately known through the array's .length property. Sometimes, a client might not even care about the torrent's hashes, and using a map/dictionary would force them to look at the keys before they can get access to the data. In the end, it isn't difficult to marshall the data as you see fit, but knowing the number of items is generally more useful than accessing by infohash, so it makes more sense to keep it as an array by default.

3. µTorrent Server has docs on the RSS requests. They'll need to be added to the API thread some time in the future. If you split the list, you'd need an independent cache ID for RSS items, on top of the torrentc cache ID already in place. That may or may not be a problem, but it isn't clearly better to split. In the end, I have previously suggested this as well though.

4. I've previously suggested this, but it won't work easily with add-url. You can't know how long it'll take for µTorrent to get the metadata, and most applications won't wait indefinitely for the backend to respond.

5. Re-read the API docs. queueup and queuedown have been implemented for a while now.

6. Re-read the API docs. Changing the labels is already possible (albeit, in a non-obvious manner). Labels in and of themselves are not manually addable/removable unless you're dealing with permanent labels, in which case you can change those via getsettings/setsetting anyway.

Basically, almost all of your suggestions either don't have clear advantages, have unresolved caveats, have been previously requested, or are already implemented.