Hey everyone...

The threatened revamped REST release is out, and with it, a bunch of new things for both REST and XML-RPC. Highlights include:

- new BETA endpoint to test your code against before it rolls out to the production endpoints. See REST docs and XML-RPC docs on the subject.

- REST is now quite a bit more verbose. All ID tags should now use the requested format, and all responses should now reside in a root container in addition to the RSP container. This is what I need feedback on more than anything else.

- new 'Heavy' flags for a few methods allow you to get heavier results, when desired, and get more data back. Methods include smugmug.albums.get, smugmug.images.get, and smugmug.users.getTree.

- smugmug.albums.getStats automatically uses a Heavy-like mode already, so you'll get images.getStats in the same call.

- new methods, including: smugmug.users.getTransferStats, smugmug.users.getTree

- renamed smugmug.accounts.getType to smugmug.users.getType. old method will, of course, continue to work but will be removed from the docs once this is out of beta.

- both interfaces now support gzip encoding (use standard HTTP header 'Accept-Encoding'). Use it, love it. I've seen responses go from 500K to 13K.

- both interfaces now support standard HTTP "If-Not-Modified" headers using ETags. Save even that 13K if you'd like if things haven't changed.

- doc bugs fixed, including smugmug.images.get, smugmug.albums.changeSettings, smugmug.albums.getInfo, and more.

- REST now properly responds in UTF-8, so foreign chars should propogate properly. Be interesting to see what happens to UTF-8 submissions. Anyone care to test a bit more?

- fixed bug in logout, should work properly now

- fixed bug in smugmug.images.delete, should work properly now

UPDATE 11am PST: XML-RPC now accepts a struct with named elements for all calls. No more worrying about the order of the elements, just make it a struct and name each one appropriately. I imagine this will probably become the standard way of doing things (no, the old way won't go away, it will just cease to be recommended or documented).

Whew. There might be more, but luckily, it's a BETA. Some of the docs have intentionally been left a little vague while we test and refine any responses to the methods. Suggestions welcome, but anything tagged with BETA in the docs is clearly not complete.

Enjoy!

Don

Don,

Looks like some great stuff here, but...
smugmug.users.getTree ??

I am going to cry
Took to hours to write and debug my code to build that exact same tree

David

Don,

With smugmug.users.getTree if Heavy is set, does that return all the images in an album ?

Thanks,

David

Originally Posted by devbobo Don, With smugmug.users.getTree if Heavy is set, does that return all the images in an album ? Thanks, David

No, it doesn't. It did for a little while in early testing, but since images aren't really part of the organization, I figured they didn't belong.

Additionally, if the call gets too heavy, it could fail to finish - I have checks for runaway calls. Some people have 60,000 photos (in who knows how many galleries), so it could get pretty enormous.

Combined with the other calls, though, this should dramatically reduce the # of calls required to accomplish almost anything.

I *might* be open to putting the images in there, but I'd have to hear a pretty compelling reason why you'd want all that stuff in a single call.

Don

No, i didn't really want it in there. I was actually worried about how large the response my be, that was the original intent of the message.

Cheers,

David

Don,

ok, a couple of questions regarding XMLRPC...

1. can't seem to retrieve the public flag, from any methods....smugmug.albums.getInfo, smug.albums.get with Heavy and smugmug.albumtemplates.get. Any ideas ?

2. using smugmug.images.get with the heavy flag, I can't retrieve ImageID ? Or is it called something else ?

Thanks,

David

Great news, Don, thank a bunch!
Sorry being too late with my response, was postprocessing:-)
It looks like many of my personal wishes came to reality:-)
I'm looking forward to get my hands dirty again:-)

Cheers!

Originally Posted by onethumb - both interfaces now support gzip encoding. Use it, love it. I've seen responses go from 500K to 13K.

It's seems like a truly great feature, but I don't seem to be able to find it in the RPC-XML docs. What do I need to do to activate it?

Thanks!

Originally Posted by Nikolai It's seems like a truly great feature, but I don't seem to be able to find it in the RPC-XML docs. What do I need to do to activate it? Thanks!

It's a web-standard via HTTP headers, really has nothing to do with the API itself, and thus, isn't documented on smugmug.

Google probably knows all about it, though. Look for HTTP specs. 'Accept-Encoding' is the header in question, I believe. ETag & If-Not-Modified headers would be in those specs, too.

Don

Originally Posted by devbobo Don, ok, a couple of questions regarding XMLRPC... 1. can't seem to retrieve the public flag, from any methods....smugmug.albums.getInfo, smug.albums.get with Heavy and smugmug.albumtemplates.get. Any ideas ?

Hmm, I see Public in a few of these just fine. I'll keep looking, though. Can you post the XML-RPC response?

Originally Posted by devbobo 2. using smugmug.images.get with the heavy flag, I can't retrieve ImageID ? Or is it called something else ?

Hmm, yeah, that would help. :)

Fixed, I think. Let me know.

Don

Originally Posted by onethumb Hmm, I see Public in a few of these just fine. I'll keep looking, though. Can you post the XML-RPC response? Hmm, yeah, that would help. :) Fixed, I think. Let me know. Don

ok...seems that the type of Public (and the other boolean flags) has changed back to INTs again....ggrrrrr

Can't seem to access the ImageID though...any thoughts ?

Thanks,

David

Originally Posted by onethumb It's a web-standard via HTTP headers, really has nothing to do with the API itself, and thus, isn't documented on smugmug. Google probably knows all about it, though. Look for HTTP specs. 'Accept-Encoding' is the header in question, I believe. ETag & If-Not-Modified headers would be in those specs, too. Don

More grinder time:-)
Cheers!

Originally Posted by devbobo ok...seems that the type of Public (and the other boolean flags) has changed back to INTs again....ggrrrrr Can't seem to access the ImageID though...any thoughts ? Thanks, David

Woops, try now. Both.

Don

getTree looks pretty slick; can't wait to get home from work and play with it.

Hey Don, any chance (still) of getting an interface into the print pricing into the API ??

--David

Originally Posted by dsdee getTree looks pretty slick; can't wait to get home from work and play with it. Hey Don, any chance (still) of getting an interface into the print pricing into the API ?? --David

Just so we're clear, the eventual goal with the API is to expose everything that A) is exposed in the web interface, and B) doesn't require SSL-grade security (ie, shopping cart, signing up for an account).

So, yes, pro pricing is on the TODO list. Who knows which year it'll get done, but it's coming. :)

Don

Originally Posted by onethumb Just so we're clear, the eventual goal with the API is to expose everything that A) is exposed in the web interface, and B) doesn't require SSL-grade security (ie, shopping cart, signing up for an account). So, yes, pro pricing is on the TODO list. Who knows which year it'll get done, but it's coming. :) Don

Pricing API would be soooo damn cool!

As noted in the first post on this thread, it's been updated with the following info:

XML-RPC now accepts a struct with named elements for all calls. No more worrying about the order of the elements, just make it a struct and name each one appropriately. I imagine this will probably become the standard way of doing things (no, the old way won't go away, it will just cease to be recommended or documented).

Don

Originally Posted by onethumb Woops, try now. Both. Don

Don,

Thanks...both are working


David

Originally Posted by onethumb As noted in the first post on this thread, it's been updated with the following info: XML-RPC now accepts a struct with named elements for all calls. No more worrying about the order of the elements, just make it a struct and name each one appropriately. I imagine this will probably become the standard way of doing things (no, the old way won't go away, it will just cease to be recommended or documented). Don

This is great news, I think it's a much more robust way of dealing with all those calls!
Thanks again!

I'm working on a Perl library for the REST API and some small clients. I hadn't read the BETA API stuff so missed out several new features (getTree, heavy requests, ...) until today. My current implementation (that doesn't use the BETA API features) uses parallel HTTP GET requests over separate connections to do a series of albums.getInfo and images.getInfo.

Without knowing about the BETA API, I was thinking that I wanted a smugmug.albums.getAllInfo that's like smugmug.subcategories.getAll and will return info for all albums for a given user. This would save clients having to enumerate each album and doing a smugmug.albums.getInfo on each one. And similarly, when getting image information for a particular album, a client has to enumerate the ImageIDs returned by smugmug.images.get and do a smugmug.images.getInfo for each one. Similarly, I had wanted a smugmug.images.getAllInfo. These both seem to be covered by the BETA API through the Heavy parameter - well done!

The reason I post, however, is to let others know that the production REST API supports persistent HTTP connections which seem like a good alternative to doing parallel connections/requests. For those not framiliar with persistent HTTP:
[FONT=Courier New]

RFC2068, describes an improvement to HTTP which maintains a continuous connection to a HTTP server for multiple requests, P-HTTP. This removes the inefficiency of continually reconnecting to a web server to download multiple images from the same page. The constant connection and reconnection results in a lot of unnecessary overhead.

Some advantages over the original HTTP protocol are:
1. By opening and closing fewer TCP connections, CPU time and memory are saved.
2. Multiple HTTP requests and responses can be sent without waiting for a response which would otherwise be necessary when opening and closing multiple connections.
3. Network congestion is reduced since there are fewer packets.

[/FONT]

With the BETA API covering my above requests, I suspect it's still a performance enhancement to use persistent HTTP. Has anybody tested the performance of persistent connections vs. parallel ones? I've fiddled with both, but only a little. I suspect the SM admins would be happier if everything went through a persistent connection.

Beware!! I'll also note that responses from the BETA REST API aren't the same as the production one. I think this has happened with adding support for Heavy requests. For example, smugmug.albums.get returns just a series of Album entries whereas the beta one returns those entries inside an Albums entry.

-m