API Update: Slight modification to JSON/PHP responses

devbobo

Hi Guys,

Just a quick heads up that JSON/PHP responses for the following methods have just changed slightly...

- smugmug.albums.get
- smugmug.users.getTree
- smugmug.categories.get
- smugmug.subcategories.get
- smugmug.subcategories.getAll
- smugmug.images.get
- smugmug.albumtemplates.get
- smugmug.albums.getStats
- smugmug.users.getTransferStats

For JSON responses, collections, such as albums or images, are currently returned as a hash...

{"stat":"ok","method":"smugmug.albums.get","Albums":{"1721":{"id":1721,"Title":"Test","Category":{"id":2,"Name":"Architecture"}},"1722":{"id":1722,"Title":"Test2","Category":{"id":2,"Name":"Architecture"}}}}

They will now be returned as arrays...
{"stat":"ok","method":"smugmug.albums.get","Albums":[{"id":1721,"Title":"Test","Category":{"id":2,"Name":"Architecture"}}, {"id":1722,"Title":"Test2","Category":{"id":2,"Name":"Architecture"}}]}


For PHP responses, collections are indexed using the ID of the object...

a:3:{s:4:"stat";s:2:"ok";s:6:"method";s:18:"smugmug.albums.get";s:6:"Albums";a:1:{i:1721;a:3:{s:2:"id";i:1721;s:5:"Title";s:4:"Test";s:8:"Category";a:2:{s:2:"id";i:2;s:4:"Name";s:12:"Architecture";}}}}

They will now be indexed starting at 0...
a:3:{s:4:"stat";s:2:"ok";s:6:"method";s:18:"smugmug.albums.get";s:6:"Albums";a:1:{i:0;a:3:{s:2:"id";i:1721;s:5:"Title";s:4:"Test";s:8:"Category";a:2:{s:2:"id";i:2;s:4:"Name";s:12:"Architecture";}}}}

I don't believe that this change should adversely effect anyone, but if it does sorry.

Cheers,

David

iamback

devbobo wrote:

For PHP responses, collections are indexed using the ID of the object...

a:3:{s:4:"stat";s:2:"ok";s:6:"method";s:18:"smugmug.albums.get";s:6:"Albums";a:1:{i:1721;a:3:{s:2:"id";i:1721;s:5:"Title";s:4:"Test";s:8:"Category";a:2:{s:2:"id";i:2;s:4:"Name";s:12:"Architecture";}}}}

They will now be indexed starting at 0...
a:3:{s:4:"stat";s:2:"ok";s:6:"method";s:18:"smugmug.albums.get";s:6:"Albums";a:1:{i:0;a:3:{s:2:"id";i:1721;s:5:"Title";s:4:"Test";s:8:"Category";a:2:{s:2:"id";i:2;s:4:"Name";s:12:"Architecture";}}}}

I don't believe that this change should adversely effect anyone, but if it does sorry.

I haven't used the API yet, but I've studied the docs to see in what way I could accomplish which tasks.

To me it seems that not indexing by the object key is a big step backward: in order to get those IDs you would then have to do another API call for each of the items. That could have a major impact on an online "browsing" type of application.

Am I missing something?

devbobo

iamback wrote:

I haven't used the API yet, but I've studied the docs to see in what way I could accomplish which tasks.

To me it seems that not indexing by the object key is a big step backward: in order to get those IDs you would then have to do another API call for each of the items. That could have a major impact on an online "browsing" type of application.

Am I missing something?

No, the ID of each element is still returned. See the example below, for both the old and current way $album returns the albumID. But the difference between the current and the old is that the $key variable is now indexed from 0, while is previously was the same value as $album

foreach($albums as $key=>$album) {
  echo $album['id'];
}

GarethLewin

So I don't use JSON, so this doesn't directly effect my efforts, but I have to ask.

What version of the API did you change? Was it 1.1 or just 1.2?

I ask because several apps (prominent within the context of this forum) have been broken. (Well I say Several, I know of two).

If you just changed 1.2.x then fine, that stuff is in beta, but I just want to be sure that the old stuff that is supposedly locked (1.1.x as of now) didn't change?

Also, can you explain what efforts are going into 1.2.0 and what are going into 1.2.1?

devbobo

GarethLewin wrote:

So I don't use JSON, so this doesn't directly effect my efforts, but I have to ask.

What version of the API did you change? Was it 1.1 or just 1.2?

I ask because several apps (prominent within the context of this forum) have been broken. (Well I say Several, I know of two).

If you just changed 1.2.x then fine, that stuff is in beta, but I just want to be sure that the old stuff that is supposedly locked (1.1.x as of now) didn't change?

Also, can you explain what efforts are going into 1.2.0 and what are going into 1.2.1?

Hi Gareth,

yes only 1.2.0 was changed...sorry I should have been clearer on that.

As for what is going into 1.2.0 as opposed to 1.2.1, generally I am only doing bug fixes or keeping 1.2.0 in line with SmugMug features...like SmugIsland settings etc. The change I just made, I decided to make it now, so developers using 1.2.0 will have a smooth transition into 1.2.1 when it's available. As for 1.2.1, I am adding new functionality and in some cases expanding existing methods.

If you have any other questions, please let me know.

Cheers,

David

iamback

devbobo wrote:

No, the ID of each element is still returned. See the example below, for both the old and current way $album returns the albumID. But the difference between the current and the old is that the $key variable is now indexed from 0, while is previously was the same value as $album

foreach($albums as $key=>$album) {
  echo $album['id'];
}

Ah, thanks - I missed that.

It does seem less logical to me though (and if I'd program such a result I would index by ID), and in the foreach loop I cannot directly use $key (not logically use it at all, in fact) but instead have to use an array item: still (slightly) less efficient - was there a pressing reason for this change?

devbobo

iamback wrote:

Ah, thanks - I missed that.

It does seem less logical to me though (and if I'd program such a result I would index by ID), and in the foreach loop I cannot directly use $key (not logically use it at all, in fact) but instead have to use an array item: still (slightly) less efficient - was there a pressing reason for this change?

The issue with returning collections indexed by ID, is that the collection basically becomes unordered, well ordered by ID...but what if the owner of the gallery had set a specific order of images, galleries etc...they no longer remain in the intended order.

iamback

devbobo wrote:

The issue with returning collections indexed by ID, is that the collection basically becomes unordered, well ordered by ID...but what if the owner of the gallery had set a specific order of images, galleries etc...they no longer remain in the intended order.

Aha! Thanks. That immediately answers another question I had not had time to ask yet! Which was: will images be returned in the order they are defined by the user.

So I guess the answer now is: they were not but now they are. That's great.