- From: Jorge Zaccaro <jorgezaccaro@gmail.com>
- Date: Wed, 30 Sep 2015 22:19:00 -0500
- To: Manu Sporny <msporny@digitalbazaar.com>
- Cc: Web Payments <public-webpayments@w3.org>
- Message-ID: <CAPnSDnP9RpzcaOm9u4fTA5erUTRiwa2kbtVbuSrpkus4hk_6Ww@mail.gmail.com>
I'd love to help with the Web Payments (REST) API. On Wednesday, September 30, 2015, Manu Sporny <msporny@digitalbazaar.com> wrote: > Hi all, > > We've been doing a bit of implementation work on the Credentials and Web > Payments work and have found a data message and API pattern that seems > like it might work for both implementation streams. > > To date, we've tried to specify how a browser could execute a payment or > credential flow using a polyfill via the use of HTTP POST/GETs, which > results in very strange form-encoding hacks to attempt to get around > deficiencies in the way you move JSON/JSON-LD data around the web via a > browser. > > This led us to design browser APIs that also relied on REST APIs to get > the job done. As Adrian pointed out in the previous post in the Web > Payments API thread, this is problematic for a variety of reasons. Among > them being that it feels awkward to Web developers because it requires > one to mix Promise-based calls with REST API calls in an unnatural way. > > So, our thinking has evolved on this topic and that has led to splitting > the messages from the Web Payments API into a separate spec called: > > Web Payments Messaging > https://web-payments.org/specs/source/web-payments-messaging/ > > The Web Payments Messaging spec defines the basic messages that > constitute the Web Payments ecosystem. They include messages for > registering payment instruments, initiating a payment (payment request), > and acknowledging the initiation of a payment (payment request > acknowledgment). > > The messages themselves are then routed to where they need to go using > protocols that are tuned to their environment. > > For example, modern browser code typically uses things like Promises to > abstract how information flows. Browser polyfills typically use > postMessage() instead of HTTP POST/GET. > > Server to server, or client-server communication that is non-browser use > REST APIs. > > Proximity and offline use cases depend on technologies like Bluetooth > Low Energy and NFC to route payment messages. > > Payments flow over all three example protocol types above and it's > important for us to take that into account and architect the solution > that the Web Payments WG is calling for with that knowledge in mind. > > So, it feels as if we're going to have at least these specs: > > Web Payments Messaging > https://web-payments.org/specs/source/web-payments-messaging/ > > Web Payments (Browser) API > https://web-payments.org/specs/source/web-payments-api/ > > and may eventually have specs for: > > Web Payments (NFC) API > Web Payments (BTLE) API > Web Payments (REST) API > > While that may seem like a lot of APIs, the APIs themselves are very > simple and lightweight. Most or all of the declarative stuff is carried > in the messages themselves. This is somewhat how ISO20022 is > architected, except that those specs don't really get into > implementation details like we'll have to for an open Web standard. > > This approach seems to be working out pretty well in practice so far. > What are the thoughts from the community? Has anyone found this approach > to be a good way of doing things? Any concerns about this approach? > > -- manu > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Web Payments: The Architect, the Sage, and the Moral Voice > https://manu.sporny.org/2015/payments-collaboration/ > > >
Received on Thursday, 1 October 2015 03:19:28 UTC