new API release - Mar 4, 2005
onethumb
Administrators Posts: 1,269 Major grins
Just rolled out a new API maint release. Mainly bug fixes, but a couple of new things too:
- NEW URL TO POST TO: api.smugmug.com/xmlrpc ... old URL will continue to work, but use the new one for all new releases. For uploads, continue to post to upload.smugmug.com.
- anonymous bug found and erradicated. should be able to do all the anonymous calls, but of course, let me know if not.
- changeAlbumSettings fixed.
- getImageURLs empty Original/Larges fixed
- getImages now orders ImageIDs by your chosen sortmethod.
- documentation errors and typos fixed
- getImages now takes a 3rd optional parameter, "TemplateID", so we can build the proper (new) AlbumURL for you. Generally, I'd leave this blank, but it's there just in case you're sure someone is using a non-Elegant template.
- getAccountType returns "Pro", "Power", and "Standard" for the logged in user. Should make your UIs a little nicer since you don't have to ask your users what they have.
- getAlbumTemplates will give you all the details on a users's album templates, which, of course, you can then use when creating an album instead of sending all the details. Your call.
- updated and added URLs to the known apps/scripts/etc. Holler if yours is missing or wrong.
That should do it. Enjoy, and cross your fingers that I didn't break anything.
Don
- NEW URL TO POST TO: api.smugmug.com/xmlrpc ... old URL will continue to work, but use the new one for all new releases. For uploads, continue to post to upload.smugmug.com.
- anonymous bug found and erradicated. should be able to do all the anonymous calls, but of course, let me know if not.
- changeAlbumSettings fixed.
- getImageURLs empty Original/Larges fixed
- getImages now orders ImageIDs by your chosen sortmethod.
- documentation errors and typos fixed
- getImages now takes a 3rd optional parameter, "TemplateID", so we can build the proper (new) AlbumURL for you. Generally, I'd leave this blank, but it's there just in case you're sure someone is using a non-Elegant template.
- getAccountType returns "Pro", "Power", and "Standard" for the logged in user. Should make your UIs a little nicer since you don't have to ask your users what they have.
- getAlbumTemplates will give you all the details on a users's album templates, which, of course, you can then use when creating an album instead of sending all the details. Your call.
- updated and added URLs to the known apps/scripts/etc. Holler if yours is missing or wrong.
That should do it. Enjoy, and cross your fingers that I didn't break anything.
Don
0
Comments
Just in case that wasn't clear enough, *only* the actual binary photo uploads should be POSTed to upload.smugmug.com. All other operations during your "upload" such as logging in and stuff should be sent to api.smugmug.com.
Clear as mud?
Don
(breathing rapidly into a paper bag) Thank you, thank you, thank you.
I'll give it a go tonight (although I'm sure there are a few other people that will beat me to it ... I can't believe that Nik hasn't responded yet).
I'll let you know if I find anything.
Aaron Christy
http://www.surfacedamage.com/
I guess I'll have a fun weekend changing SE..:):
Seriously, very glad you finally had a chance to fix the stuff..
---
Guys, let's post your quick findings and confirmations here, so we don't all have to spend time over simple things, like what works and what not..
----
Cheers!
In the apps section:
- is it possible to change the formatting in a way it does NOT depict everybody else as a plugin to SendtoSmugmug?
- I personally would appreciate if you set the order to alphabetical or chronological (FIFO)..
Thank you!Cheers!
We had a mini-meltdown in the morning, and right about Don's post time another serious issue came back..
I guess we all gonna have some fun with our apps tonight...:):
Cheers!
Changed URL to go to api instead of upload.
Recompiled SE and ran all basic scenarios (sorry, didn't build separate QA facility yet:-)
Thus far SE only untilizes what I tend to call "old" API, most of them circa fall 2004 (with some bugfixes and friend/family/sorting related novelties circa January 2005).
As a result of these tests, the good news is:
what was working - still works
Seems like no damage was done as a side effect of the new changes.:):
As a partially bad news: what was not working - still does not.
Again, I'm only talking about the old API, from which the only non-working method was anonymous login.
"Partially": as far as I mostly interested in upload and other "priviledged" actions, anonymous login was of purely academic interest to me (translation: don't really care:-).
Here's the list of verified APIs:
Working:
- loginWithPassword
- loginWithHash
- logout (works even with anonymous login)
- getCategories
- getSubCategories
- getAllSubCategories
- getAlbums
- multipart upload (aka upload via POST)
Not working (* see below):- loginAnonymously
[EDIT]I can login and logout, but none of the above command works, response being
invalid user (4)
*) As we established in a discussion below, this is a behavior by design. As far as anonymous session does not know about any particular account, most of the account specific methods will return empty/invalid resutls.
So it works, but the limits of its work are really narrow..
I guess that concludes it for me - I'm gonna drop anonymous support from SE
[/EDIT]
Didn't test:
Hope you guys will bring more test cases!
HTH
Cheers!
As to the order - I guess one can never reach all his goals, something has to be left to desire
Cheers!
Nik,
I didn't get home until late so I really haven't had a chance to do a very thorough test, but the one method I was most interested in was loginAnonymously.
I was able to get it working correctly and call getImages/getAlbums/etc. without any problems.
The session ID returned from the loginAnonymously seemed valid and without issue.
-Aaron-
Aaron Christy
http://www.surfacedamage.com/
Aaron,
I guess it's a good news.
Thank you for pitching in:-)
Let me double check a few things, now that I know that it may work:-)
I'll post the results asap.
Cheers!
I'm also using it fine. What are you seeing, Nik, that isn't working?
Don
Aaron, Don
I tried again and again - still cannot get it work.. :cry
Can you guys do me a favor and look at this dump - may be you spot something stupid?:uhoh
[PHP]
0:05:45: Started Logging in anonymously
0:05:45: Post to https://api.smugmug.com/xmlrpc/
<?xml version="1.0"?>
<methodCall>
<methodName>loginAnonymously</methodName>
<params>
<param><value>1.0</value></param>
</params>
</methodCall>
0:05:45: Post results
<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse>
<params>
<param>
<value>
<struct>
<member>
<name>SessionID</name>
<value>
<string>a7c35117f0fb367f1e7b20c865669f99</string>
</value>
</member>
</struct>
</value>
</param>
</params>
</methodResponse>
0:05:45: Finished Logging in anonymously (0:00:01)
0:05:45: Logged in: Session: a7c35117f0fb367f1e7b20c865669f99; User: ; Hash:
0:05:48: Started Gettings list of albums
0:05:51: Post to http://api.smugmug.com/xmlrpc/
<?xml version="1.0"?>
<methodCall>
<methodName>getAlbums</methodName>
<params>
<param><value>a7c35117f0fb367f1e7b20c865669f99</value></param>
</params>
</methodCall>
0:05:51: Post results
<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value>
<int>4</int>
</value>
</member>
<member>
<name>faultString</name>
<value>
<string>invalid user</string>
</value>
</member>
</struct>
</value>
</fault>
</methodResponse>
0:05:51: RPC-XML: invalid user (4)
0:05:51: Finished Getting albums for PhotoSoCal (0:00:00)
[/PHP] </FONT>
</FONT>
Any idea what am I doing wrong? Same code works fine with non-anonymous login.
TIA
Cheers
I thought maybe the problem was that I was logging in using https and was doing other requiests via plain http.
Did more tests, used various combinations - both secured, both non-secured, ect - same stuff..
The problem is that you're not giving getAlbums any sort of indication which user you'd like albums for.
Remember, you're logged in anonymously, so there's no user associated with your session. getAlbums() can only do one of two things: send you all albums on smugmug, or send you none. Since I don't want to send you all, I have to send you none.
Hope that helps!
Don
Thanks.
Anyone else still having problems with changeAlbumSettings or getImageEXIF ?
For me, changeAlbumSettings is returning a response XML with unpopulated elements.
And getImageEXIF is returning the error "Invalid User".
Cheers,
David
SmugMug API Developer
My Photos
Thanks for the updates to the API.
Last night I went to bed, still thinking about what am I doing wrong - and just before I disconnected from reality I got this revelation: as far as I do not provide any account information for login, session id does not carry it - hence there is no way in hell this call possibly could work - which you just confirmed:-)
Now that we established that I am stupid and that anonymous session does dont carry any account info, I have a question - what methods can possibly work with anonymous login?
Thanks!
(Side note: I can't figure out how to post XML without it getting stripped!)
In Nik's example his method call has a methodCall/params/param/value node where the 1.0 string goes.
Based on XML-RPC standards, shouldn't it be: methodCall/params/param/value/string ?
In which case, this method call will fail.
Don/Nik, thoughts?
Aaron Christy
http://www.surfacedamage.com/
That "string" part is "by dafault" and can be omitted at sender's discretion.
Judging by the fact that I'm using the same "request generator" for all my RPC-XML calls and they all work (including getting session id from anonymous login), I think it's ok to skip it..
HTH
Cheers!
I guess my point is exactly that -- I have to skip it. Otherwise, the method call appears to fail. Every other call I've tried works fine using "string".
Unfortunately, this means for this one single method call (loginAnonymously), I have to create a new method on my components that does not adhere to strict XML-RPC standards for it to work.
I would prefer that the SM API accept standard XML-RPC formatted requests by default and then after that, if they want to be more lenient, that's fine.
It would make things easier for everyone that way.
Aaron Christy
http://www.surfacedamage.com/
.. as long as there is a fork allowing to skip it - at least for backward compatibility.
Not that it would make my life too hard (I have total control over my requests and it would be a very simple adjustment in one place), but I don't want exisiting code suddenly stop working on dozens (or, worse, hundreds) of machines where it has been already installed... Being a one-man army, I simply don't have enough resources to respond to this kind of the meltdown properly.
So, Don, whatever you decide to do, please keep original API intact or 100% backward compatible - or, at least, give us a fair warning so we can deliver the message to our users.
Just my $.02
Cheers!
Ok, I must be missing something.
First, the XML-RPC spec specifies that any value which doesn't have a type declared is a string. So AFAIK, I'm adhereing to spec. Nik didn't want to send a type, so I assume string. Big deal.
Second, I just tested it with the following layouts, which worked:
methodCall/params/param/value
methodCall/params/param/value/string
Third, "Version" isn't currently used for anything, it's there for future use should the API not be backwards compatible at some point. So you could send me just about anything in loginAnonymously, right now, and it would work fine.
So, as far as I can tell, everything works as designed, and it works to spec. What, exactly, is the problem?
Don
There's no way I'm promising 100% backwards compatibility. Thus far, it's been easy, but there might come a point where we need to break compatibility.
That's what "Version" is for, so I can safely deprecate older clients over a period of time, and eventually return "invalid version" to them.
Currently, I don't see what all the hooplah is about - the XML-RPC spec says you can specify string or not, as you wish. Nothing is broken, AFAICT.
Don
It would seem to me really useful to expose these smugmug methods that currently are sent to http
In order to understand recursion, you first have to understand recursion.
Art Hill
Hey Don,
Thanks for setting me straight on that -- I didn't realize the type would automatically default to string.
I switched to a more efficient way of generating XML-RPC calls and my loginAnonymous call keeps failing (fault code 7 - anonymous login not permitted). The request looked fine when comparing it against Nik's original posting, so I figured that not defining the type was the problem.
I'll investigate further this evening and see what turns up. If it still doesn't work, I'll throw the request out here to see if anyone has any ideas.
Thanks!
Aaron
Aaron Christy
http://www.surfacedamage.com/
First of all, I don't even have the problem with the [string] thingie <STRING>:-)
Second, I understand importance of providing "latest and greatest", and was only asking for a fair warning period in case compatibility cannot be achieved.
I can even help you to beta-test your new features if you need me to.
I'm sure other guys would like it to, so when you actually roll them out, our smugmug-dependent s/w is ready, or, at least, aware.
Cheers!
I think I'm missing the point here...
XML-RPC is an industy-standard interface for providing "web services". Together with REST and SOAP, they are easily the most common web service interfaces on any website, big or small.
So we are already providing web services ... are you wanting a different interface to the API? I'm not sure we'll ever provide SOAP (I'm liking it less and less as time goes on), but REST is definitely a possibility.
Don
May I ask why? I am honestly interested in your opinion..
I think I know where he is coming from with this. With web services, it automatically generates html on the server documenting the API.
David
SmugMug API Developer
My Photos
The WS-I Basic Profile actually disallows the use of SOAP encoding. This is a good indication that rpc/encoded will indeed become deprecated over time. For more information on this, see "The Argument Against SOAP Encoding" on MSDN® Online." Aaron Skonnard at http://msdn.microsoft.com/msdnmag/issues/03/05/XMLFiles/
We need WSDL! I'm definitely a rookie at all this stuff but was able to quickly figure out how to use Web Services at Amazon and can't figure out what to do with XML-RPC. I am skeptical of your claim that XML-RPC is the most common web services interface.
But, I'm not trying to start an argument and you probably know a hell of a lot more about this than I do. I just want a WSDL file so I can program to a proxy and not have to get my hands dirty.
In order to understand recursion, you first have to understand recursion.
Art Hill