Options
REST users: Heads up!
onethumb
Administrators Posts: 1,269 Major grins
There are some new API calls coming out soon, and some changes to a couple of existing ones.
As requested by a few people, the REST API's output format is starting to move away from 1:1 matching to the XML-RPC format.
Basically, the XML is becoming a little "heavier" for a few of these new calls, and I'm going to want feedback from everyone using REST as to whether they're good or bad. I can see both sides.
As an example, a call which would grab a bunch of AlbumID and ImageIDs would look something like this today:
<method>blah</method>
<Album id="1">
<Image id="1" />
<Image id="3" />
</Album>
<Album id="2">
<Image id="2" />
</Album>
would now look more like this:
<method>blah</method>
<Albums>
<Album AlbumID="1">
<Images>
<Image ImageID="1">
<Image ImageID="3">
</Images>
<Album AlbumID="2">
<Images>
<Image ImageID="2">
</Images>
</Albums>
As you can see, there are essentially new container wrappers. I'm not totally sure whether I like id="X" or AlbumID="X" better, so I'll leave it up to you -- what do you prefer?
I'd like to get people's thoughts now, and then have the REST people ready to play with and report back once they're out in the next few days.
It'd also be nice to get a show of hands for who's using REST. I'm a huge fan and vastly prefer it to XML-RPC.
Preliminary thoughts?
Don
As requested by a few people, the REST API's output format is starting to move away from 1:1 matching to the XML-RPC format.
Basically, the XML is becoming a little "heavier" for a few of these new calls, and I'm going to want feedback from everyone using REST as to whether they're good or bad. I can see both sides.
As an example, a call which would grab a bunch of AlbumID and ImageIDs would look something like this today:
<method>blah</method>
<Album id="1">
<Image id="1" />
<Image id="3" />
</Album>
<Album id="2">
<Image id="2" />
</Album>
would now look more like this:
<method>blah</method>
<Albums>
<Album AlbumID="1">
<Images>
<Image ImageID="1">
<Image ImageID="3">
</Images>
<Album AlbumID="2">
<Images>
<Image ImageID="2">
</Images>
</Albums>
As you can see, there are essentially new container wrappers. I'm not totally sure whether I like id="X" or AlbumID="X" better, so I'll leave it up to you -- what do you prefer?
I'd like to get people's thoughts now, and then have the REST people ready to play with and report back once they're out in the next few days.
It'd also be nice to get a show of hands for who's using REST. I'm a huge fan and vastly prefer it to XML-RPC.
Preliminary thoughts?
Don
0
Comments
What about method calls that do not return arrays such as getInfo. Would this return
<method>smugmug.albums.getInfo</method>
<Album>
<AlbumID>000000</AlbumID>
...
<FriendEdit>1</FriendEdit>
</Album>
instead of
<method>smugmug.albums.getInfo</method>
<AlbumID>000000</AlbumID>
...
<FriendEdit>1</FriendEdit>
This would be nice since it would be consistent with the other format changes. And, as I said earlier, it would make parsing the XML easier.
As for id="x" or AlbumID="x", either one would be fine though id="x" is lighter.
Bill
The thought is to make all REST calls return an array. Perhaps not formatted exactly as you have it, but close. Probably drop the AlbumID key/value pair and instead make it a parameter of the array itself, for example.
Don
I am developing with REST as it was more lightweight and better suited by situation.
In the situation like <Album AlbumID="1"> I would prefer to have the attribute name simply "id" since otherwise it's redundant.
I have a side question to this topic. With these new API calls, will there be a call like smugmug.images.getInfo but with the ability to retrieve information for multiple images? When I have an album and I want to retrieve info on all the images, I have to make SO many calls which understandably takes quite a while. My intention is to get all the image information from an album with the smallest number of calls. Retrieving information from all the images in the album may be extreme, depending on how many images there are. It may require a 'page' parameter.
Thoughts?
I don't care one way or the other what the response format is, but are you really sure you want to have different formats for XML-RPC and REST? I thought the point of REST was just to make the request side simpler. What's the justification for making the response side different too? Do people think XML-RPC's response format is too complicated, or what?
XML-RPC's response format is fairly limited and cumbersome.
There are lots of REST libraries out there that expect nested arrays and iterate through them.
Currently, the way XML-RPC and REST's output formats differ given the same array of elements causes some difficulty to those who already have used REST and expect smugmug's output to "just work". I want it to "just work" also, so I'm hoping we can get a little closer.
The output formats will remain similar, and provide the same information, but more in line with what the rest of the industry seems to be doing.
Don
Was sorta hoping I'd get more of a response, but I suppose that might be it for REST users given it's new state.
Hopefully tomorrow, but if not, probably early next week. I'm busy this weekend.
Don
Logout via REST gives 'Invalid API Key' error
http://www.dgrin.com/showthread.php?t=10851
Is this going to be fixed?
Invalid XML Format on REST response
http://www.dgrin.com/showthread.php?t=10550
Is this a documentation error or is it going to be fixed?
smugmug.images.getInfo (all?)
http://www.dgrin.com/showpost.php?p=99815&postcount=4
Any thoughts on supporting this?
As long as XML-RPC interface stays on par with the REST I don't think I'm gonna switch - that is unless you tell me that REST part is faster or "wider".
It was nice to meet you:-)
Cheers!
Sorry, I was too busy fixing things to reply. Happens sometimes, and I apologize.
They should all be fixed in the current beta release. Please let me know, on the BETA thread, if not!
Don
-J