new API release - March 31st, 2005

onethumb

BIG changes! Here are the highlights:

- method names have dramatically changed. The old methods will still work, and probably will forever, but no promises. I strongly suggest you start using the new naming scheme. See the docs.

- new interface! REST! Some would argue it's even simpler than XML-RPC, and they might be right. See the docs.

- APIKeys! To curb abuse and increase our ability to track API usage, all uses of the API now require an API key. Easy to apply for, quick to obtain, you'll need it to use any of the new functions, new REST interface, etc. See the docs.

- New methods to let you manipulate Categories & SubCategories: rename, delete, etc.

- Stats methods to get hits and bytes sent per album and per photo.

- Bug fixes to quite a few methods to return the proper values (ints, bools, etc) and results.

I'm sure I've introduced bugs, so holler if you find some.

Don

devbobo

Don,

smugmug.images.get & smugmug.albumtemplates.get are returning method not found


David

onethumb wrote:

BIG changes! Here are the highlights:

- method names have dramatically changed. The old methods will still work, and probably will forever, but no promises. I strongly suggest you start using the new naming scheme. See the docs.

- new interface! REST! Some would argue it's even simpler than XML-RPC, and they might be right. See the docs.

- APIKeys! To curb abuse and increase our ability to track API usage, all uses of the API now require an API key. Easy to apply for, quick to obtain, you'll need it to use any of the new functions, new REST interface, etc. See the docs.

- New methods to let you manipulate Categories & SubCategories: rename, delete, etc.

- Stats methods to get hits and bytes sent per album and per photo.

- Bug fixes to quite a few methods to return the proper values (ints, bools, etc) and results.

I'm sure I've introduced bugs, so holler if you find some.

Don

rutt

Are you planning on maintaining xml-rpc as well as rest? I hope so. Python support of xml-rpc is first class, but not so for rest.

Don, I think it would be really great when you have a change like this that is going to break everything, to publish the documentation, changes, etc, in advance and give us some time to get ready. Please?

Cameron

rutt wrote:

Don, I think it would be really great when you have a change like this that is going to break everything, to publish the documentation, changes, etc, in advance and give us some time to get ready. Please?

I agree -- I first noticed my PHP script returning an error and dug through the code for a bit before I came here to read about the API changes. A simple "the API will be changing" heads-up would have been helpful, even without other details. Perhaps a 1 week "grace period" where API calls work without keys would have been helpful.

Nikolai

Thank you!
As long as the old functionality keeps working "as is", at least for the time being, I'm all up for the changes!

I agree, sort of advance notice would be nice, but hey, sometimes $%it just happens:-)

I'l looking forward to see the REST:-)

One question: is your intension to
1) support/uprdage *both* branches (rpx-aml & rest),
or
2) the rpc-xml gets to rest:-) and REST will be the "main" API?

Thanks again for keep an eye of this area!

Cameron

Nikolai wrote:

As long as the old functionality keeps working "as is", at least for the time being, I'm all up for the changes!

I agree, but the old functionality isn't working "as is" -- I don't have an API Key yet and my scripts using the old API calls are failing due to 'invalid API key'. :cry
Oh well - I'm sure once I get the API Key things will work very well. I think it's great that Don and the rest of the crew are so actively trying to make the API a useful and powerful tool.

onethumb

rutt wrote:

Are you planning on maintaining xml-rpc as well as rest? I hope so. Python support of xml-rpc is first class, but not so for rest.

Don, I think it would be really great when you have a change like this that is going to break everything, to publish the documentation, changes, etc, in advance and give us some time to get ready. Please?

I did rigorous backwards compatibility testing so I really shouldn't have "broken everything".

Note what's not working that used to work and I'll get it fixed.

Don

onethumb

CSwinton wrote:

I agree -- I first noticed my PHP script returning an error and dug through the code for a bit before I came here to read about the API changes. A simple "the API will be changing" heads-up would have been helpful, even without other details. Perhaps a 1 week "grace period" where API calls work without keys would have been helpful.

All existing functionality continues to work, without Keys.

Come on guys, I'm not that stupid. There's a huge grace period where all the old calls work, there's no key required for anything that was old, etc etc.

If something's not working, it's an honest mistake and a bug, not intentional. Tell me which call isn't working, rather than complaining with zero details.

Don

onethumb

Obviously, the docs aren't clear enough, though it seems like it to me.

For the record: Both REST and XML-RPC will be jointly updated in lockstep. XML-RPC isn't going anywhere.

Of course, also for the record, the APIs are currently sans official support or endorsement. Use at your own risk.

Don

rutt

onethumb wrote:

All existing functionality continues to work, without Keys.

Come on guys, I'm not that stupid. There's a huge grace period where all the old calls work, there's no key required for anything that was old, etc etc.

If something's not working, it's an honest mistake and a bug, not intentional. Tell me which call isn't working, rather than complaining with zero details.

Don

Sorry. Zero details is right. I didn't even test. I just read what you wrote and assumed that you were announcing that it wasn't going to work. Sorry if I read it wrong, but it wasn't 100% clear and I didn't sleep so great last night anyway.

I'll test and let you know.

onethumb

devbobo wrote:

Don,

smugmug.images.get & smugmug.albumtemplates.get are returning method not found


David

Silly typos. I assume you were talking about the XML-RPC interface?

Try now.

Don

onethumb

onethumb wrote:

BIG changes! Here are the highlights:

Oh, yeah, and the API endpoints changed again. Just to be clear, the old endpoints still work and should continue to work for a long long time, but I'd shift to using the new ones (which are permanent, now, I promise!) for all future work.

Don

rutt

Smugmug.py does seem to work. Next time I'll try to be more empirical. Sorry.

Thanks, Don, for all the work on this. It really is a pleasure to have this interface.

Cameron

onethumb wrote:

All existing functionality continues to work, without Keys.

Come on guys, I'm not that stupid. There's a huge grace period where all the old calls work, there's no key required for anything that was old, etc etc.

If something's not working, it's an honest mistake and a bug, not intentional. Tell me which call isn't working, rather than complaining with zero details.
Don

If I thought you were stupid would I be paying you money? Sorry for the lack of details. I have a PHP script and am using XMP_RPC (with old API for the moment). "loginWithPassword" fails due to 'invalid API key'. Using the API key I just received, it works perfectly. Any idea why the old call with the API key would fail? I'm not sure (being new to this) which other details would be helpful - please let me know what else you need.

onethumb

CSwinton wrote:

If I thought you were stupid would I be paying you money? Sorry for the lack of details. I have a PHP script and am using XMP_RPC (with old API for the moment). "loginWithPassword" fails due to 'invalid API key'. Using the API key I just received, it works perfectly. Any idea why the old call with the API key would fail? I'm not sure (being new to this) which other details would be helpful - please let me know what else you need.

The API key for XML-RPC should only kick in if you're sending a Version that's equal to or greater than "1.1.0".

What Version are you sending?

Don

Cameron

onethumb wrote:

The API key for XML-RPC should only kick in if you're sending a Version that's equal to or greater than "1.1.0".

What Version are you sending?

Don

That was it - I was sending "1.1". Thanks for the quick replies and sorry for any confusion. I didn't think about version control in the API. That's what I get for posting messages on little sleep. Now I know.

Would there be any advantage, in PHP, to use the REST interface? The XML-RPC classes available for PHP seem to work well. Thanks.

Nikolai

Just tested with one week old SE

CSwinton wrote:

I agree, but the old functionality isn't working "as is"

Works like a charm. no api key, no rest.
Prolly something on your side, my man!

Cheers!

onethumb

CSwinton wrote:

That was it - I was sending "1.1". Thanks for the quick replies and sorry for any confusion. I didn't think about version control in the API. That's what I get for posting messages on little sleep. Now I know.

Would there be any advantage, in PHP, to use the REST interface? The XML-RPC classes available for PHP seem to work well. Thanks.

Whew. Glad to hear.

The interfaces are essentially identical, so which one to use is left up to the author. Both interfaces are easy to use and lightweight (as opposed to SOAP), so you can't really go wrong with either one.

Don

dds

No REST
Hi, I just got my API key and I'm trying to give the REST API a shot but so far I've had no luck, just a lot of invalid API key errors

As a quick check that it should be working, in my browser I've been trying to hit this URL:
https://api.smugmug.com/hack/rest/?method=smugmug.login.anonymously&Version=1.1.0&APIKey=RealAPIKeyHere
with or without SSL, the response is invalid API key. AFACT this should be just like the sample request in the docs. Does it work for anyone else? If so, what browser/OS are you using?

onethumb

dds wrote:

Hi, I just got my API key and I'm trying to give the REST API a shot but so far I've had no luck, just a lot of invalid API key errors

As a quick check that it should be working, in my browser I've been trying to hit this URL:
https://api.smugmug.com/hack/rest/?method=smugmug.login.anonymously&Version=1.1.0&APIKey=RealAPIKeyHere
with or without SSL, the response is invalid API key. AFACT this should be just like the sample request in the docs. Does it work for anyone else? If so, what browser/OS are you using?

Give it a shot now.

Don

dds

onethumb wrote:

Give it a shot now.

Don

Works! Thanks very much!

Domino

Does SOAP really suck ?

onethumb wrote:

Whew. Glad to hear.

The interfaces are essentially identical, so which one to use is left up to the author. Both interfaces are easy to use and lightweight (as opposed to SOAP), so you can't really go wrong with either one.

Don

Hi Don,

First of all I am new to this forum and just discovered the Smugmug API yesterday, although I am a Smugmug member for some time already. I really think this API is a bright idea!

Now about SOAP, I think if it does really suck or not is not the right question at least for two reasons:

• As soon as you use the right tools to implement SOAP Web Services at server and client level, you do not have do worry about SOAP since you wont have anything to do with it, SOAP is handled by the WS platform you use. Two completely different and very good WS platforms are the Java one from Sun and the MS .NET.
• SOAP Web Services are really getting well supported now, and will open your API to a wide range of users and developpers on any kind of platform.

I was not either that enthousiast about Web Services since as a consultant I HAD to investigate different solutions and develop WS based applications for one of my customers.
If you ever want some more details feel free to direct mail me.

Dominique

onethumb

Domino wrote:

Hi Don,

First of all I am new to this forum and just discovered the Smugmug API yesterday, although I am a Smugmug member for some time already. I really think this API is a bright idea!

Now about SOAP, I think if it does really suck or not is not the right question at least for two reasons:

• As soon as you use the right tools to implement SOAP Web Services at server and client level, you do not have do worry about SOAP since you wont have anything to do with it, SOAP is handled by the WS platform you use. Two completely different and very good WS platforms are the Java one from Sun and the MS .NET.
• SOAP Web Services are really getting well supported now, and will open your API to a wide range of users and developpers on any kind of platform.

I was not either that enthousiast about Web Services since as a consultant I HAD to investigate different solutions and develop WS based applications for one of my customers.
If you ever want some more details feel free to direct mail me.

Dominique

I'd hate for this to become a religious issue, so I'll try to be brief and just state that I've done quite a bit of research and quite a bit of playing around and it just doesn't seem to make sense.

Look at our API. It's incredibly simple, yet also incredibly powerful. SOAP adds so much more weight and complexity to something that really should be simple and elegant. It would take me a much longer time to build a SOAP interface than it did to do both REST and XML-RPC combined.

As a semi-final note, I've chatted with Jeff Bezos and Jeff Barr at Amazon about their web services (Jeff Barr is the guy in charge of that stuff there). They tell me that 85% of the AWS usage is REST, hardly any SOAP, and that processing and returning a REST call is 6X faster than a SOAP call. I believe both numbers, both from personal experience and comparing notes with the web services guys at eBay, PayPal, and Google.

In an interesting parallel, I've been a part of web application teams using Java in the past, and I have huge complaints about Java that closely parallel SOAP. Java may be great for doing complex things more easily, but it sure makes doing simple things far too complex. It's slow, bloated, difficult to scale, and really just gets in the way for something "simple" like a web application, IMHO. So I'm not terribly surprised that Java and SOAP play nicely together - they seem to have the same design mentality.

Whew. Hopefully this post hasn't started The Crusades all over again.

Don

Domino

onethumb wrote:

I'd hate for this to become a religious issue, so I'll try to be brief and just state that I've done quite a bit of research and quite a bit of playing around and it just doesn't seem to make sense.

Look at our API. It's incredibly simple, yet also incredibly powerful. SOAP adds so much more weight and complexity to something that really should be simple and elegant. It would take me a much longer time to build a SOAP interface than it did to do both REST and XML-RPC combined.

As a semi-final note, I've chatted with Jeff Bezos and Jeff Barr at Amazon about their web services (Jeff Barr is the guy in charge of that stuff there). They tell me that 85% of the AWS usage is REST, hardly any SOAP, and that processing and returning a REST call is 6X faster than a SOAP call. I believe both numbers, both from personal experience and comparing notes with the web services guys at eBay, PayPal, and Google.

In an interesting parallel, I've been a part of web application teams using Java in the past, and I have huge complaints about Java that closely parallel SOAP. Java may be great for doing complex things more easily, but it sure makes doing simple things far too complex. It's slow, bloated, difficult to scale, and really just gets in the way for something "simple" like a web application, IMHO. So I'm not terribly surprised that Java and SOAP play nicely together - they seem to have the same design mentality.

Whew. Hopefully this post hasn't started The Crusades all over again.

Don

Although it doesn't have anyhing to do with a religious issue, I am afraid I cannot agree with you.
Anyway, I will not argue, it doesn't make any difference form me if you have or not a SOAP WS API. Just my 2 cents.

Congrats again for Smugmug.

Dominique

jef

I can't upload successfully with the new API. I'm using the new version string, new URLs, and my API key. When I try to call "http://upload.smugmug.com/hack/xmlrpc/ smugmug.images.upload" I get a method not found fault. When I switch the method name back to the old deprecated "upload", the upload works but the result I get is just an empty string, as if the API version was pre-1.0. Since my code depends on getting back the ImageID as the result, it thinks the upload failed.

I'm sure I could hack around this by ignoring the results from the upload and figuring out the new ImageID using smugmug.images.get, but I'd really rather not. Please look into this ASAP.

Nikolai

Jef,

jef wrote:

I can't upload successfully with the new API. I'm using the new version string, new URLs, and my API key. When I try to call "http://upload.smugmug.com/hack/xmlrpc/ smugmug.images.upload" I get a method not found fault. When I switch the method name back to the old deprecated "upload", the upload works but the result I get is just an empty string, as if the API version was pre-1.0. Since my code depends on getting back the ImageID as the result, it thinks the upload failed.

I'm sure I could hack around this by ignoring the results from the upload and figuring out the new ImageID using smugmug.images.get, but I'd really rather not. Please look into this ASAP.

It looks like your got your pawns all mixed up.
New method name does not work with this url.
Check the doc.

HTH

onethumb

jef wrote:

I can't upload successfully with the new API. I'm using the new version string, new URLs, and my API key. When I try to call "http://upload.smugmug.com/hack/xmlrpc/ smugmug.images.upload" I get a method not found fault. When I switch the method name back to the old deprecated "upload", the upload works but the result I get is just an empty string, as if the API version was pre-1.0. Since my code depends on getting back the ImageID as the result, it thinks the upload failed.

I'm sure I could hack around this by ignoring the results from the upload and figuring out the new ImageID using smugmug.images.get, but I'd really rather not. Please look into this ASAP.

For XML-RPC, you do *not* want to use the XML-based submission methods, like http://upload.smugmug.com/hack/xmlrpc/smugmug.images.upload.

See the docs on "Uploading via POST".

Don

jef

I know about uploading via POST. I wrote my code to upload via XML-RPC to keep things simpler. It used to work. Are you saying you are no longer supporting that option?

What about the missing method name?

What about the empty string return?

Nikolai

Upload via POST

jef wrote:

I know about uploading via POST. I wrote my code to upload via XML-RPC to keep things simpler. It used to work. Are you saying you are no longer supporting that option?

What about the missing method name?

What about the empty string return?

I am using Upload via Post, and I am using RPC-XML - all since last November.
New API requires new url.
Upload via Post simply posts to the special (old) url, no method name is needed.

As to the errors you're getting - since you're using mismatching methods/urls/versions you can get all sort of funny things back:-)

Just follow the documents in the hack section.
Or download S*E, check all the logging options on and use the results as the working example.

HTH

Good luck!

jef

I don't know what you mean about mismatching. As far as I can tell I am following the current docs.

jef

Ok, while I was waiting for you to fix the bugs in uploading via XML-RPC, I decided to try uploading via POST. Again I am using version 1.1.0, my API key, and the new URLs. Following the instructions on the "XML-RPC: Uploading via POST" page, I posted to the URL "http://upload.smugmug.com/photos/xmladd.mg". This URLs times out. Uploading via POST does not work for me.

I also re-checked my previous findings. XML-RPC to "http://upload.smugmug.com/hack/xmlrpc/ smugmug.images.upload" gives a method not found fault. If I use the new URL with the deprecated method name "upload", the upload succeeds but the response is an empty string.

I remain without any working upload path.