Support for API v2.
Opened this issue · 16 comments
Are there plans to support v2?
Yes. I have started work on this.
You can see the current progress in the v2/master branch.
@xyzcl I have just merged a very early prototype into master if you want to take a look.
Thanks Alex, will take a look when I get a chance to and report back.
No rush! :)
Had a quick look at the new code. Do tell me if I'm being stupid, but the patching parts have not been enabled as of yet?
The patch request for modified properties is here.
You should be able to change the properties of the object and the call SaveAsync.
I am still working on 2 pieces of the API:
- getting the methods that require a POST request (like image!color or image!crop)
- creating new objects
I am also going to cleanup the code (by removing all of the auto-generated methods in *.methods.cs) -- at the very least I will make all of those internal to hide them from IntelliSense.
I stand corrected -- the change to patch an object is not wired up in this code yet -- I will submit a PR shortly with it.
I have submitted #15 to enable the Save and some other methods that use POST.
I have published a version of this API as a Nuget package (you can get it by running: Install-Package SmugMug.Net.v2Api -Pre.
That version is obviously not ready but it should cover at least the retrieving of objects and saving changes.
Thanks for the save method. I wanted to do a patch an Image, but this seems not possible as the Image was retrieved from an Album. I hacked around to get an Image using the Image key (and added a "-0" to the end, not sure why I needed to do this), and that allowed me to do the save.
I know about the -0 part -- no idea why... weird :).
And you are saying that once I get the Image from an Album it cannot be patched? I wonder if I simply need to send the request to a different Uri.
It's not always -0, sometimes it's a -1, I haven't seen anything else, but it suggests -n can be added to the key.
The images (AlbumImage) you get from the album has the URI:
https://api.smugmug.com/api/v2/album/SJT3DX/image/jPPKD2c-1
And this cannot be patched, the image (Image) you can patch is:
https://api.smugmug.com/api/v2/image/jPPKD2c-1
I basically hacked it the Image class to contain a method to get another Image using the 2nd URI.
In smugmug's documentation (https://api.smugmug.com/api/v2/doc/reference/album-image.html) it mentions that the AlbumImage is different than Image because an Image can be part of multiple Albums.
Aha! Makes total sense!
What I can do in that case is something similar to the EntityId. Basically have a PatchUri on the base class that each class can override (if they have to). By default, PatchUri and Uri would be the same.
And I had never seen the -1 at the end... Do you know how they are decided?
On Mon, Jan 4, 2016 at 2:27 PM -0800, "AlexGhiondea" notifications@github.com wrote:
Aha! Makes total sense!
What I can do in that case is something similar to the EntityId. Basically have a PatchUri on the base class that each class can override (if they have to). By default, PatchUri and Uri would be the same.
And I had never seen the -1 at the end... Do you know how they are decided?
—
Reply to this email directly or view it on GitHub.
I don't know the reason for the number at the end or how they decide to add it. Tried to find something in the docs regarding this but had no luck.
I have noticed that in the result of the AlbumImage URI, there is the correct Image URI with the number . Perhaps this can be used somehow?
_____________________________
From: AlexGhiondea notifications@github.com
Sent: Monday, January 4, 2016 22:27
Subject: Re: [SmugMug.NET] Support for API v2. (#1)
To: AlexGhiondea/SmugMug.NET smugmug.net@noreply.github.com
Cc: xyzcl xyz.chenling@gmail.com
Aha! Makes total sense!
What I can do in that case is something similar to the EntityId. Basically have a PatchUri on the base class that each class can override (if they have to). By default, PatchUri and Uri would be the same.
And I had never seen the -1 at the end... Do you know how they are decided?
—
Reply to this email directly or view it on GitHub.
Maybe. I have another case where the information comes back as part of the Uris collection so I was considering creating a way to parse information from that respose as well.