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.
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. 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. 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). 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. 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. -Justin > On Nov 20, 2015, at 2:36 PM, Jim Porter <[email protected]> wrote: > > On 11/19/2015 11:19 PM, Justin D'Arcangelo wrote: >> What NGA brings to the table, in this regard, is the ability to craft >> an easy-to-consume developer API for the app. When we talk about >> separating the front-end from the back-end in terms of “NGA”, we are >> really talking about defining this developer API for the back-end and >> exposing it via an HTTP API. This allows a traditional web developer, >> who is used to working with server-side HTTP APIs, to jump right in >> and get up and running. > > How does an HTTP API make things easier than a similarly-designed (and > likely more-expressive) Javascript API? I absolutely disagree that NGA > provides any new abilities to create pleasant APIs for the backend of an > app. While using HTTP internally might allow for some new features (like > running the backend on a different system), that doesn't mean that the > API itself needs to expose this, nor does it mean that the *interface* > has improved because of it. > > Since Firefox OS assumes that all our apps will be written in > Javascript, why not take advantage of that property and write the API > for our backend *as* Javascript? I doubt that any "traditional web > programmer" would be confused by a Javascript-based API as opposed to an > HTTP-based API. > > To be clear, if we can get significant performance gains from using HTTP > and Service Workers internally (e.g. by taking advantage of caching), > then by all means, let's use it. However, our experience with Service > Workers hasn't borne this out yet, and it still doesn't mean that the > easiest-to-use API would be HTTP-based instead of Javascript-based. Even > if we used HTTP internally, we might find it preferable to expose an API > that takes advantage of all the syntactical niceties of modern > Javascript. In fact, this is pretty common in many languages, even ones > where HTTP fetches are super-easy: somewhere on top of the HTTP API lies > a language-specific API that handles query-building and response parsing > for you. These "wrapper" APIs can reduce the verbosity and improve the > readability of any calls to the HTTP endpoint > > - 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
