Re: [webpayments] Should a payment request be just data, or a programmable object? (#36)

> So, what is our design approach for the browser API?

I assert that our design approach should be: "There is data and functions act on that data"

There are at least three reasons to take this approach:

1. It helps us clearly delineate the payment messages from the things you can do with those payment messages (this helps us more easily use the same messages for the HTTP API and the browser API and align w/ ISO20022).
2. It simplifies the browser API and thus reduces the cognitive load on developers as it's clear that you have payment data and things you can do with that payment data.
3. It avoids unnecessary complexity in the browser implementations by making the browser just a payment message router instead of exposing a payment request state machine to the payee.
4. It's more flexible, as a data-only approach decouples behavior from the data.

There is much more on the downsides of object-and-verb API design here:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/36#issuecomment-164996826