On 11/20/2015 01:55 PM, Justin D'Arcangelo wrote: > Traditional web developers are *very* familiar with HTTP APIs as > pretty much all web applications on the open web rely on an HTTP > back-end (think Twitter clients, FB clients, etc). In contrast, many > of our own JavaScript-based Device APIs do not feel “webby” and more > closely resemble the types of APIs you would see on native platforms > like iOS or Android. That’s not to say we don’t need those types of > APIs (we absolutely do), but to your average web developer, they can > be *very* intimidating.
Are you sure about that? The non-Mozilla web developers I know are all familiar with things like jQuery, Angular, React, etc (not necessarily all at once). These are just Javascript APIs, and I'd be very surprised if web devs described them as "intimidating". In any case, I don't think we should optimize for "traditional" web developers anyway, since > Note, I’m not necessarily opposed to exposing a JS API for our > back-ends. However, in doing so, you would almost certainly end up > seeing vastly different APIs across all our apps as there is no > “standard” pattern for the design of these APIs. Luckily, we all work at the same company and can communicate with each other what "shape" our APIs should be. :) In individual teams, e.g. the media apps, the API designers might even be the same people. Then, you'd end up with very-similar APIs for Gallery, Video, and Music. > By sticking with HTTP, you will inherently have some level of > consistency between APIs for all of our apps — especially if we > follow a REST-like pattern. I don't see a lot of potential for consistency with HTTP APIs, except in the boring parts (e.g. boilerplate syntax). Without cross-team communication, the names of resources will probably vary widely, as would the conventions of what to pass as a parameter. Heck, these could vary even among versions of the *same* app! For instance, the Music app's backend currently takes filenames of individual songs to refer to an album, whereas in the future, we might pass an album ID to reduce the number of database queries on the backend. In a Javascript-based API, however, we could hide that change from users by simply accepting a full metadata object for a file as the parameter, and then extracting the appropriate info inside our backend's implementation before the DB query. Following conventions like this could make a JS-based API *more* consistent than an HTTP-based alternative. > You would also be set up for doing all sorts of new things in the > future with regards to splitting the app across multiple devices > (front-end on phone/back-end on desktop, etc). While there are certainly benefits to doing things like this, I imagine that in many cases, technologies like this already exist, and it would be wiser for us to use them rather than invent our own HTTP API. For instance, if we split up the media libraries from the UI, a likely choice for communication would be UPnP/DLNA, since we'd then have interoperability with a wide range of *other* devices. While UPnP is effectively an HTTP API, it's not quite the kind that we'd design on our own, since it uses XML as opposed to JSON, has a separate protocol (RTSP) for the actual media data, and features strange things like HTTP-over-UDP. In any case, if the performance issues with Service Workers remain, it may be better to provide a non-HTTP mode of communication if you're dealing with a database on the same device as your UI. > Also, it should certainly be possible for apps to use a thin JS > “wrapper” around their back-end HTTP APIs as well. In fact, it is > fairly common to see APIs on the open web being offered this way *in > addition to* a plain-vanilla HTTP API (think Google Maps, Twitter, > etc.). However, this only affects the way a developer *consumes* said > API. The way a developer uses an API is all an API is. Everything else is an implementation detail. One of the reasons Google Maps, Twitter, etc provide public documentation for their HTTP APIs is because it allows applications written in arbitrary languages to communicate with them. For Android, iOS, and desktop platforms, this can be pretty important. However, since Firefox OS was designed from the ground up on the assumption that all code is written in (or compiled to) Javascript, that reason no longer applies. > In the end, the back-end service still exposes an HTTP API > under-the-hood and offers a thin JS library for developers mostly as > a convenience. In API design, I'd say convenience is everything. - Jim _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
