Developing for Enterprise Cloud Storage
Google and Dropbox are household names while Box is in the headlines for its ongoing IPO. However, the enterprise cloud storage space is a completely different landscape, with various companies like SugarSync, Egnyte, Bitcasa, and Citrix ShareFile all competing for companies’ cloud storage needs. What should you, as a developer, consider when addressing enterprise customers’ concerns?
Citrix ShareFile Features
ShareFile recently revamped their API, transitioning from an HTTPS endpoint to an ODATA specific HTTP Rest API. As a developer, the new API looks like many others, offering a familiarity and ease to integrate functionality. However, a few unique features separate ShareFile from the rest.
Control Planes (with Subdomains)
Like many other API providers, Citrix ShareFile implements the OAuth 2.0 protocol for authorization. ShareFile’s endpoints are:
- Request Token
- Access Token
- Refresh Token
- API requests
The authentication endpoint is separate from API requests based on Control Planes. The Control Plane separates user authentication, access control, reporting, and brokering from where any corporate data is stored. Enterprises can now feel safe about their data as Citrix’s service offers an API to interact with that data. In addition, the subdomains allow for user creation, which is extremely important for CIOs, enterprises, and other groups. As a developer, I notice that the <appcp> corresponds to a specific control plane (sharefile.com, securevdr.com, etc.), which must be tracked.
In this diagram, you’ll notice the second feature of Citrix ShareFile’s architecture: Storage Zones. Citrix ShareFile gives you the flexibility to choose where corporate data is stored with Citrix-managed Storage Zones or Customer-managed Storage Zones in two flavors: Amazon S3 or Microsoft Azure. Plainly, some companies want their corporate data on premise or on their own servers. This is a great feature for an Enterprise cloud storage provider. Now, as a developer, how does all of this affect me?
The underlying product architecture of Citrix ShareFile gives insight into how the API is structured. Most endpoints look familiar, but I will highlight the key similarities and differences.
The Items endpoint is the typical interface to a user’s files and folders. ShareFile has specifically exposed the following entities: File, Folder, Note, Link, and Symbolic Links. Each item entity has its own OData representation with the corresponding functions to create folders, retrieve folder contents, update an item, and even create links to specific items.
Storage Centers and Zones endpoint
The Zones and Storage Centers allow for interaction through the API. This is extremely important if companies want to deploy private storage centers or zones. Other cloud storage providers do not have or expose this functionality because of the architecture. One thing to keep in mind as a developer is that a user’s data may be spread across different storage centers and zones, but to a user, it appears as a single account.
Kloudless and ShareFile
At Sharefile’s Synergy Conference in early May 2014, interesting new features were announced. ShareFile can now connect not only to Sharepoint but a few other enterprise content platforms like Alfresco, Documentum, and Filenet. The connection theme continues, with the Kloudless API allowing developers to connect to enterprise and consumer cloud storage services through a standard API interface. Kloudless gives the developer flexibility in choosing what cloud storage features to integrate into their product including native functionality and user interface components. If you want to develop for users with both personal and company cloud storage accounts, you can get started quickly and easily with Kloudless — we’ll help!
Take a look at developers.kloudless.com as we continue to improve our developer friendly resources (SDKs, API mashups, and example apps)! Have any ideas or questions about the Kloudless API? Leave your questions and comments below, or drop a note to email@example.com.