Re: [w3c/webpayments-payment-apps-api] The relationship between payment apps and service workers (#33)

@marcoscaceres,

> If you can avoid having an external JSON resource, please do so.

One reason for expressing the manifest as JSON is for reuse in other environments. It follows the [Rule of Least Power](https://www.w3.org/2001/tag/doc/leastPower.html) design principle.

This manifest will likely specify a title, icon/image, and other basic information about a Payment App. A Payment App may be registered with the browser and may use JavaScript (via a service worker), but it could also potentially be provide HTTP endpoints for use with the Web Payments HTTP API. Other APIs could also be specified in the future to access the same Payment App. The manifest could be reused here to provide that same information to a payment mediator or to other applications that wish to render some kind of interface for working with it outside of the browser.

By expressing this information as JSON in an external resource -- it means that the Payment App implementer only needs to do so in one place.

Now, an argument could be made that Payment Apps that provide multiple APIs could, for example, in their service worker do a fetch to obtain their manifest, parse it, and then provide it as JavaScript to the `paymentAppManager` interface. And perhaps that's the model we'll end up with. But I wanted to explain one rationale for having an external manifest and for expressing it in the least powerful programming language. There's a greater potential for Payment Apps than just their use within the browser. Choosing a design that allows us to reuse various aspects of them may result in less burden for the developer and more serendipitous innovation in the future.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/33#issuecomment-247026916