- 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