- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Sun, 22 Jan 2017 22:57:42 +0100
- To: Adrian Hope-Bailie <adrian@hopebailie.com>
- Cc: Interledger Community Group <public-interledger@w3.org>
On 2017-01-22 22:37, Adrian Hope-Bailie wrote: > <snip> > The secondary problem is signatures. > > > Could this be solved with HTTP Signatures and SRI? Yes it could. So why don't I use it? If you re-read my paper you will find the word "transport-independent". postMessage in a browser is 100% compatible with my scheme but 100% incompatible with REST/JSON-RPC. The same goes for WebSockets and JavaScript. I'm already using this feature extensively in my proof-of-concept systems: https://github.com/cyberphone/saturn/blob/master/desktop-client/test/test.html#L24 <snip> >>> add unnecessary complexity however it's also worth considering how addressing >>> a REST API suddenly changes when the client and server support HTTP2. >> That's more interesting. How do you see that this will/should affect bank-to-bank transactions? > I don't know enough about HTTP2 to say Neither do I so ignore my comments if they are off. > but I think HTTP Push willbe influential Yes, but hardly in bank-to-bank transactions. > as will the ability to re-use a connection (as I understand things) Yes, multiplexing can be used but if I understand it correctly this does not make it necessary dropping the existing request/response scheme. Anders > > > > Anders > > > On 22 January 2017 at 22:39, Roberto Santacroce Martins <r@bravado.com.br <mailto:r@bravado.com.br> <mailto:r@bravado.com.br <mailto:r@bravado.com.br>>> wrote: > > Nice article +1 thanks > > Em 22/01/2017 18:24, "Anders Rundgren" <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>> escreveu: > > On 2017-01-22 19:00, Adrian Hope-Bailie wrote: > > Hi Anders, > > I found your analysis interesting and useful. > > > Thanx. > > I must say though, if you conclude that REST is not suitable for this use > > > case why not use something entirely different like JSON-RPC? Your proposed > > new transport seems like it would be a great candidate. > > > Maybe I want to be different? :-):-) > > No that was just a joke, JSON-RPC seems to map directly to the POST profile (note that there is a GET profile in my scheme as well). > I say "seems" since the JSON-RPC spec is extremely terse and version 2 doesn't actually specify a HTTP binding at all! > > That I in my own implementations do not want to use JSON-RPC is because it "interferes" which what I consider "sacred", the messages. > > JSON-RPC: > > {"jsonrpc": "2.0", "method": "PayMeNow", "params": ["amount": "265.00"], "id": 6} > > > "Anders-RPC": > > { > "@context": "https://standards.org/payments <https://standards.org/payments> <https://standards.org/payments <https://standards.org/payments>>", > "@qualifier": "PayMeNow", > "amount": "265.00", > "id", 6 > } > > JCS (The signature scheme) is incompatible with the JSON-RPC specification as it stands. The same goes for JWS (JOSE). > > The absence of security solutions makes JSON-RPC less useful for Internet-based transaction systems. > > > There are other things related to my "Message Centric" scheme which I haven't described and that is that if you for example do a postMessage() in a browser there is no return value *which doesn't map at all to REST or JSON-RPC*. > > Anders > > Adrian > > On 22 January 2017 at 18:01, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>>> wrote: > > Maybe of some interest... > > https://cyberphone.github.io/doc/web/REST-in-peace.html <https://cyberphone.github.io/doc/web/REST-in-peace.html> <https://cyberphone.github.io/doc/web/REST-in-peace.html <https://cyberphone.github.io/doc/web/REST-in-peace.html>> <https://cyberphone.github.io/doc/web/REST-in-peace.html <https://cyberphone.github.io/doc/web/REST-in-peace.html> <https://cyberphone.github.io/doc/web/REST-in-peace.html <https://cyberphone.github.io/doc/web/REST-in-peace.html>>> > > Enjoy! > Anders > > > > > > >
Received on Sunday, 22 January 2017 21:58:18 UTC