Should we be publishing a specification for an HTTP API?

[msporny]

Should we create a message flow for non-browser, HTTP-only clients?

[msporny]

Yes, we should (this is important for non-interactive payments): http://web-payments.github.io/web-payments-http-api/

[mattsaxon]

+1

[mountainhippo]

++

Nick Telford-Reed
e: [email protected]
m: +447538177619
On 2 Dec 2015 12:47 p.m., "mattsaxon" [email protected] wrote:

+1

—
Reply to this email directly or view it on GitHub
#17 (comment).

[adrianhopebailie]

+1

[msporny]

I may have been mistaken, but I heard that an HTTP API is "not in scope" during our last call. I vaguely remember @adrianhopebailie saying that personally he feels that it's really important, but our charter doesn't call it out as a deliverable. Looks like we have preliminary consensus to propose an HTTP API as a WG deliverable (citing that a browser-only API wouldn't meet our broader 'user agent' API requirement).

@adrianhopebailie @mountainhippo can we get this on the agenda for the next call and do a straw poll to see if we have approval to create and publish an HTTP API as a FPWD in March?

[dlongley]

+1 to an HTTP API is in scope and should be worked on (at least minimally to ensure we don't paint ourselves into a corner) in parallel with the browser API and messaging specs.

[adrianhopebailie]

I am fully in support of us publishing an HTTP API spec but think that we should keep the group focused on the JavaScript API right now as this is where we have the most momentum.

Rather than trying to define the messaging first and then the API's after, I propose that we allow the JavaScript API design to mature (we need to have an FPWD by March) and as such the messaging schemas will have stabilized.

At this point, if we have not already done so, we can extract the messaging schemas from the JavaScript API specification into it's own document which is a normative reference for both API specifications.

This document will likely be a valuable reference in it's own right for non-developers as it may include guidance on how the Web Payments messaging relates to other technology such as the ISO20022 data dictionaries and vocabularies.

I would like to propose therefor that we don't attempt to produce an HTTP API FPWD for our March delivery deadline. If there is general support for this I will log a formal proposal and put it on the agenda for 28 Jan.

[bifurcation]

I'm not opposed to an HTTP API, but I agree with @adrianhopebailie that it's in a distant second place after the JS API. I think that if we get the JS API right, payment providers will be able to implement a variety of HTTP APIs behind the scenes. That doesn't mean that defining a standard one isn't useful, though.

[ianbjacobs]

My thoughts:

• Previously, I thought it would be great to strive for a March publication of an HTTP API. We are chartered to produce one, and I'd like us to show progress on this front.
• I also thought it would be valuable to allow the APIs to evolve independently, and as we understand the needs of each more clearly, seek (but not require) harmonization between them.
• However, I agree with Adrian's observation that the JS API feels today like the primary one, and therefore I support focusing our energies on it first. I hope this will enable us to solidify it more quickly, and ultimately reduce churn on the HTTP API design.

Ian

[adrianhopebailie]

We have a proposal now at: https://w3c.github.io/webpayments/proposals/web-payments-http-api/
Please log any issues against that proposal with the label Proposal: HTTP API