What is the Camera to Cloud API?
The Camera to Cloud (C2C) API offers a way to send media directly into Frame.io the moment recording stops with no additional input from the user of your device, while maintaining strong security guarantees. It is our vision at Frame.io that the moment a user stops recording — or makes a metadata entry — their media is available for them in Frame.io to review and collaborate.
When we sat down to make this vision a reality, it became clear that to offer the best experience for both integrators and users, we needed to make the C2C API it's own mini "backend", distinct from the rest of Frame.io's ecosystem. This might not seem like an obvious choice at first glance, why not just use the existing API?
In this article we will lay out the specific goals and philosophy of C2C by exploring its guiding principles.
Bytes to Cloud
First, let's dispel a false impression. Camera to Cloud was named with the Rule of Cool — it's alliterative, evocative, and looks great on swag. But it's also a bit of a misnomer. Does your device and / or App create bits? Do you want those bits in Frame.io as soon as possible? Is that all you really need your device and / or App to do?
Camera to Cloud might be right for you!
We don't really care what the bits are. Sound, Video, PDFs — Frame.io will accept any file type. We thought Visual Audio And Other Media Plus Supporintg Documents To Cloud sounded better, but we got overruled by Marketing. For some reason.
Write, but don't read
Frame.io takes its security guarantees very seriously, and allowing devices to communicate affords a new vector for bad actors. Many cameras, sound recorders, and other physical media devices don't have passwords, screen locks, and other security features because they are not traditionally connected to the web. If we were to give access to the full Frame.io API to these devices, they could become possible security breaches if left unattended.
Additionally, the person operating the device might not even be someone who should be given access to the greater project. Their job might simply be to create some of the media, not manage all of it.
That lead us to a broader point: Cameras exist to create media, not review or comment on other devices' media, so the way to solve a potential security problem is to make an API that is bounded purely to the problem we are trying to solve anyway: writing data to the cloud. The best way to stop bad actors from reading data they shouldn't? Don't make it possible to read that data in the first place.
Where we're going, we don't have GUIs
Frame.io's existing APIs make an assumption: you are writing an App. That App wants to talk to Frame.io. That app has a GUI, just like our app. We assume we can send you a list of things, you can display that list to the user, and the user can decide to take some action on that list which in turn is communicated back to the server.
But with devices, now our "app" is not really an App at all. It's a physical device which may or may not even have a GUI. Which may or may not support user input at all.
When designing C2C, we had to ask ourselves: could we integrate this API on a pager? Unfortunately, React.js has yet to release support for pagers, so a much simpler way of interacting with the user had to be targeted. A way that did not require the user to make any sort of input on the device, since in many cases they might not be able to.
That ruled out the existing API on another front: We can't redirect to a webpage to sign in, can't count on the user being able to enter a username / password. Can't count on the user being able to select a folder to drop their footage into. We didn't need to just pair down what actions a device could take, but the entire experience around accomplishing those actions.
We also kinda don't have internet?
Not only do our devices not have necessarily have a traditional GUI, they also might not have access to consistent internet. So we needed to design our API in a way to not require tons of communication to the backend — to keep the number of calls required during operation to an absolute minimum so that camera operators on remote sets with spotty WiFi or Cellular service could still have a good experience.
Make integration simple
Lastly, we needed to make integration as simple as possible. A handful of endpoints, minimal requirements for back-and-forth negotiating with the server, and a small surface area laser-focused on what it is we actually want to accomplish. We recognize that this might be the first set of third-party network calls some of our integrators are writing! Whether you are experienced with REST API's and just want to get through integration as fast as possible, or this is your first time writing an HTTP call, we want your experience to be as smooth and painless as possible.