MUFF WIGGLER Forum Index
 FAQ & Terms of UseFAQ & Terms Of Use   Wiggler RadioMW Radio   Muff Wiggler TwitterTwitter   Support the site @ PatreonPatreon 
 SearchSearch   RegisterSign up   Log inLog in 
WIGGLING 'LITE' IN GUEST MODE

Squiggletronics RackPlanner Library - API information
MUFF WIGGLER Forum Index -> RackPlanner  
Author Squiggletronics RackPlanner Library - API information
BananaPlug
There is now an API w00t

Developers interested in using software to access library content can start here and ask questions and make suggestions in this topic.

nanners

2012-11-07 Bug Fix for URLs like /modlib/api/id/{FORMAT}/{MANUF} and JSON returned is now always in object form.
synthcube
super awesome
much value in this
thanks
solitud
Looks good and will definitely help people out!
Some things I recognized on the first view:

1. Somewhere in the docs should be mentioned that searchparams like manufacturers should always be urlescaped, else kids will wonder how to query "XAOC Device". And is everything caseinsensitive?

2. I am not sure if the komma separated query http://squiggletronics.com/modlib/api/module/1,2,3
should be urlescaped also?

3. The moduleImageFilename field has not much practical value in the result, because people can not access it. Shouldn't this be a link in the future?

4. http://squiggletronics.com/modlib/api/id/{FORMAT}/{MANUF}
Is there a bug or am I doing it wrong?
http://squiggletronics.com/modlib/api/id/e/Doepfer
responds the same like
http://squiggletronics.com/modlib/api/id/e

5. http://squiggletronics.com/modlib/api/module/1
This returns a Javascript object.
http://squiggletronics.com/modlib/api/id/e
This returns a Javascript array.
That's fine but it could lead to strange errors if people assign arrays to objects in Javascript and via versa. For consistency maybe return everything as object?

6. Error Handling
I know everyone likes things a little different. I prefer the Error messages be part of the response object, so:
http://squiggletronics.com/modlib/api/module/1

leads to:
{success: true, result : {"1":{"properties":{"id":"1","manuf":"4ms", ... }}}
or:
{success: false, msg: {"Module not found"}}
or
{success: false, msg: {"API traffic has exceeded"}}

I don´t want to rant, it´s fantastic job!
Thanks, Knut
BananaPlug
Good points. Thank you.

1 & 2 - Well of course. That's why we have urlencoding but you are absolutely right I should point it out. Will save somebody some grief. Yes, case insensitive.

3 - Well, you can simply ignore it. It may be helpful to someone who's interested in following changes to a module.

4 - BUG, I broke something. That was working a few days ago and I didn't think I'd done anything to change it. It's now fixed.

5 - The default is more "economical" using the simplest data structure but for the sake of simplifying the explanation of the API I'll take your suggestion. It's now changed.

6 - Yeah, lots of ways to go. It's okay for now.

Will be posting news of any updates in this thread and summarizing in first post.
dougcl
BananaPlug wrote:

3 - Well, you can simply ignore it. It may be helpful to someone who's interested in following changes to a module.



This means that a client cannot keep up with image changes. The question really is whether or not the image is fundamental to the module definition. If it isn't, then users will be in the position of finding and uploading images to many databases. If it is, then at least in theory, the images can be uploaded once, and the location reused. From a user perspective the latter is preferable, but there might be bandwidth metering issues. There is nothing to keep someone from writing a planner that hits the image server on every module access, for example.
BananaPlug
Just to clarify about the moduleImageFilename property. This is the filename of the image which is inside the module zip.

There's no rule about what name to use in the first place but if you are reconstituting a zip from data you should preserve the name. Theoretically we could use the same name all the time but historically this has not been what's done. In the ModuleMaker (source of most of the modules) the filename of the uploaded image is sanitized a bit and appended to a 4 digit number. Thus we have a lot of moduleImageFilename values like "5277divider_module.jpg"

Quote:
The moduleImageFilename field has not much practical value in the result, because people can not access it. Shouldn't this be a link in the future?

Which people? When? If you're a developer pulling stuff from the library the moduleImageFilename property is something you would use when building a zip from that information. The API instructions tell you how to form a URL for obtaining the image from the library. I imagine some developers will gather zip files from the library and just use them as is. Other developers will go further, gathering the module properties and images into their own database and perhaps generating module zips from that as needed but quite possibly not using zip files at all. Using the API you can find the module ids and then get the module data (XML properties and some additional info), image, or zip file using the ids.

Quote:
There is nothing to keep someone from writing a planner that hits the image server on every module access

If that happens much I can restrict access. We're on the honor system so far. I think the API provisions are sufficient that a developer can responsibly maintain an up to date copy of any module on their system.
dougcl
BananaPlug wrote:
The API instructions tell you how to form a URL for obtaining the image from the library.


Ah, I missed that. Sorry.
MUFF WIGGLER Forum Index -> RackPlanner  
Page 1 of 1
Powered by phpBB © phpBB Group