Two important lacks to fix to make the Office 365 File API really rock
At the time of writing (08/2015), Office 365 is really becoming a great platform with a lot of APIs for a very affordable and competitive price. As I'm currently involved in OneDrive for Business implementation, I focused on the File API whose the main endpoints is:
and I consider it a good start. The integration with Azure Active Directory is awesome (also with the other services) but the API itself lacks two major features to rock:
- First of all, it should be fully OData compliant. Today, the SKDs provided by Microsoft cannot do more than just adding a file and downloading a file. If the endpoint was capable of handling OData's string functions such as substringof, it would enable some search capabilities. Indeed, you find a file based partially on its name. Today, either you already have its ID (which is unlikely to happen unless you've uploaded the file yourself, either you have its path. But what if you want to find all .docx files etc...With a fully OData compliant API, such scenarios would be possible. Of course, performance might become a problem. As an alternative, they might add a search endpoint behind the /files/ one which would behind the scenes leverage SharePoint Search
- As the File API is used to handle files, it'd be great to have something to handle large files. The Azure Blob Storage REST API ships with the possibility to deliver file blocks. That's particularly interesting when uploading large files because in case of failure, you can just try to resend the latest block instead of reuploading the entire file
Note that this two lacks (search capability and large file support) are covered when it comes to the OneDrive API ( https://dev.onedrive.com/odb-preview/release-notes.htm ) but they are not there yet with OneDrive For Business which is still in preview. This is also a little unclear what should production users do in the future? Should we stick to the Files API or should we move? Moving will clearly represent a cost.