> On Nov 20, 2015, at 3:23 PM, Jim Porter <[email protected]> wrote: > > 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 >
Let’s ask the dev-rel team what they think about this :-) We are trying to grow our number of contributors. Anything that lowers the barrier of entry and follows well-established patterns in the community helps. Also, I’m not referring to jQuery, Angular, etc. which all have *well-documented* syntax with easy-to-follow examples. I’m talking about things like DeviceStorage, MozCamera, etc. There was just a thread the other day where someone did not understand how to enumerate a directory with DeviceStorage, so I’d say that this *is* a problem. >> 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. > Using that logic, all our Gaia apps should currently have similar design patterns and coding standards. Is anybody here going to seriously argue that we already have that?! >> 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. > Versioning an API is something that happens all the time with HTTP APIs. Usually all that’s needed is a bump in a version number to change the URL pattern (e.g. /api/v2/…). >> 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. If we are going to support other 3rd-party HTTP APIs in the back-end, why on earth would we design a back-end that’s *not* HTTP? If you are proposing that we have a thin JS wrapper that maps JS calls to HTTP calls, then I’m all for it. But, it seems to me that if we wanted our app to run on a UPnP back-end, we would effectively have to expose our own UPnP services through an HTTP API, right? > >> 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. This doesn’t make sense. If the back-end API is *not* HTTP, then what is the transport? We should not assume that client and server will always be on the same device if we want to scale up for the future. > >> 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 _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
