none
REST API 5.0: PUT upload of photos is totally random

    Soru

  • I tried to upload photos as File objects using the Skydrive REST API 5.0 and PUT requests. I did what I was asked to do in the documentation (empty Content-Type, file data in the request body) and tried every possible request URL approach that was listed:

    Make a PUT request to /UPLOAD_LOCATION of the parent folder's ID.
    Make a PUT request to /FOLDER_ID/files/filename.
    Make a PUT request to /UPLOAD_LOCATION for the file to update.
    Make a PUT request to /FILE_ID/content.

    With my two test files I tried this (both JPG files with a resolution of 4000x3000 pixels) the first file was transferred as expected as a file, the second file was transferred as a photo, was reduced to 2048x2048 max size had the same behavior as a photo. The upload responses confirmed that:

    String sent from server {

        id = "file.1871bb3945d14179.1871BB3945D14179!243";

        source = "http://storage.live.com/s1pKAfgwWUUBlyo08buPxFUcAbxxJltqKnDjaKBLpOhMlX4DvS4W_5wsNgpcmerw_Qq2sbIcdOsrdQ2y3d9akvZWxAtf-nvxEZU5yj4IHuAU62jj5XVmBlKdBXMF7Z_c0y3/IMG_0012.JPG:Binary,Default/IMG_0012.JPG";

    }

    String sent from server {

        id = "file.1871bb3945d14179.1871BB3945D14179!244";

        source = "http://storage.live.com/s1pKAfgwWUUBlyaOwFc4z-oSlHoyK8pg__5CxhFEd0hrA6qb4PI-IfQamy3jGYwnefjPCzHOqk0IDEe3d6t5-9EkVSja9Q_N9XseqsBioNQbxHzY2tliB6U93-Ntgnyv7g2/IMG_0011.JPG:HighRes,Default/IMG_0011.JPG";

    }

    This behavior is the same if I only transfer one of these files at a time. As you can see, with the same PUT upload request, IMG_0011.JPG ALWAY ends up as a HighRes photo object while IMG_0012.JPG is always (as it should be) a Binary file object.

    Why is the API behaving so random? If this is not working as it is intendend, then the whole API is totally useless. I need to offer a reliable upload services and the user has to decide if he wants to upload his pictures as photos or as files. But with this random behavor this is not possible. Is this API just crap or are there any hidden settings that are mentioned nowhere that I have to apply to get the expected behavior?

    Best regards,

    Helmut

    19 Nisan 2012 Perşembe 08:10

Tüm Yanıtlar

  • This looks like a bug on our end. Do you have the two original images hosted somewhere online so we can attempt to reproduce this behavior? 
    20 Nisan 2012 Cuma 20:39
  • Hi,

    these are the two photos.

    http://dl.dropbox.com/u/363242/IMG_0689.JPG
    http://dl.dropbox.com/u/363242/IMG_0690.JPG

    IMG_0689.JPG is always uploaded as a photo while IMG_0690.JPG is always uploaded as a file.
    In both cases I used the PUT request to /FOLDER_ID/files/filename REST API call.

    But despite these two pictures it is happening very often that photos that I am sending with the PUT request to /FOLDER_ID/files/filename are ending up as photos on Skydrive.

    The whole photo/file, album/folder thing looks like a complete conceptual mess to me. Why is it necessary to define a photo either as a photo or as a file and let the user make this decision? I am sure that most users will never understand why some of their photos end up as files and some others as photos. Just add different views for photo files and you'll never have this problem. If I - as a developer - do have my problems with your 'concepts', how should a simple and straight thinking user be able to understand this?



    • Düzenleyen hschottm 24 Nisan 2012 Salı 06:01
    24 Nisan 2012 Salı 05:58
  • Thanks for providing this data. This is a bug that our development team is now investigating. 

    I do want to clarify that there isn't a notion of a user choosing that an image is considered a file or a photo. All images should be treated as photos with the attendant metadata about the photo such as thumbnails created on upload. That this isn't happening for an uploaded JPEG is a bug. 

    25 Nisan 2012 Çarşamba 11:31
  • Ok, so let me rephrase that in my own words if I understand this correctly:

    • if I use a working REST API in the future and I upload photos using a PUT request to /FOLDER_ID/files/filename, the photos will be treated like a photo in the web interface (thumbnail generated, metadata info, etc. etc.) and the photo will not be resized to 2048x2048 pixels. This should be possible with all images automatically that are recognized as photo by Skydrive
    • I need to create only Folder objects where I store my photo files and the photo files will be shown in the web interface under 'Photos' 

    Is this correct so far, because other behavior makes absolutely no sense for me? If I look at the Skydrive Mac Client, I only see folders (no albums) and if I upload photos to Skydrive these photos are not modified and in their original size and available as photos in the web interface (well except the buggy ones like above, the Mac client has the same problem with my two example images except that the image that was recognized as photo was unmodified and with original size while the one uploaded using the REST API was resized to 2048x2048 px).

    What I still don't understand is that using the Mac client or the Windows client I can upload EVERY file type to Skydrive but with the REST API I am limited to some photo and document file extensions...

    We are running a well respected photo app iOS and I am sure that our users will not understand why it is possible to upload RAW files (.NEF, .CR2, ...) to Skydrive with the Mac or Windows client but not with our iOS app which uses the REST API. I would be great if you could review this meaningless restriction and create a consistency between the Web / OS client behaviors and the developer API's.

    25 Nisan 2012 Çarşamba 13:15
  • Thanks for the clarifications. It would be super helpful to the team in tracking down these issues if you could share the photos that are having problems. It seems the links to your DropBox are now 404ing. 

    With regards to RAW files, this was a temporary restriction we put in place due to some issues we had with regards to recognizing RAW files as photos. It would be helpful if you could provide the list of RAW file extensions that your app cares about. 

    26 Nisan 2012 Perşembe 13:40
  • Sorry,

    seems that someone deleted the photos. They're back online. The Dropbox links should now work.

    http://dl.dropbox.com/u/363242/IMG_0689.JPG
    http://dl.dropbox.com/u/363242/IMG_0690.JPG



    26 Nisan 2012 Perşembe 13:46
  • Thanks for the clarifications. It would be super helpful to the team in tracking down these issues if you could share the photos that are having problems. It seems the links to your DropBox are now 404ing. 

    With regards to RAW files, this was a temporary restriction we put in place due to some issues we had with regards to recognizing RAW files as photos. It would be helpful if you could provide the list of RAW file extensions that your app cares about. 

    Well, we support all available RAW files. Here's a complete list of extensions:

    http://en.wikipedia.org/wiki/Raw_image_format

    Cheers,

    Helmut

    26 Nisan 2012 Perşembe 13:50
  • Hi Dare,

    just one more thing: Every RAW file usually has a JPEG preview. Why don't you just scan the incoming files for JPEG bytes, then you'll know it is picture. And you can easily create a preview/thumbnail for the file. That's what Apple is doing on all their iOS devices.

    Cheers,

    Helmut

    26 Nisan 2012 Perşembe 13:56
  • Hi Dare,

    just one more thing: Every RAW file usually has a JPEG preview. Why don't you just scan the incoming files for JPEG bytes, then you'll know it is picture. And you can easily create a preview/thumbnail for the file. That's what Apple is doing on all their iOS devices.

    Cheers,

    Helmut

    This is a good suggestion and we'll look at adding support for this in a future release. Thanks for the great feedback. 
    27 Nisan 2012 Cuma 08:48
  • Great, you guys fixed it. But please explain me why the REST API resizes all photo file uploads to 2048 px max?

    This makes totally no sense: The Mac and Windows clients are able to transfer the original photo files to Skydrive and the REST API resizes large photos and removes the EXIF metadata.

    How should a developer be able to build a consistent product compared to your official clients which obviously use private API's...

    It is still not a valid behavior according to the REST API documentation where there is NO word that PUT requests to /FOLDER_ID/files/filename will resize the files...

    What's the problem with you...


    03 Haziran 2012 Pazar 18:34
  • Great, you guys fixed it. But please explain me why the REST API resizes all photo file uploads to 2048 px max?

    This makes totally no sense: The Mac and Windows clients are able to transfer the original photo files to Skydrive and the REST API resizes large photos and removes the EXIF metadata.

    How should a developer be able to build a consistent product compared to your official clients which obviously use private API's...

    It is still not a valid behavior according to the REST API documentation where there is NO word that PUT requests to /FOLDER_ID/files/filename will resize the files...

    What's the problem with you...

    I totally agree and I have been asking this since long ago and no one gives an answer. Downsize to 2048 and loosing EXIF data such as date taken, GPS position are a big disappointment for most users.
    05 Temmuz 2012 Perşembe 16:05