- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Sun, 22 Jan 2017 23:07:47 +0200
- To: Roberto Santacroce Martins <r@bravado.com.br>
- Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CA+eFz_LQ0zOLuAvnk7RmS2XOo7QsdedGPLQS61hWrVVDbyojBg@mail.gmail.com>
I interpret JSON RPC 2.0 differently. Noting that params can be an object ( http://www.jsonrpc.org/specification#request_object) and could therefor contain everything an HTTP POST contains and more. I'd say this: { "jsonrpc": "2.0", "method": "https://standards.org/payments/PayMeNow", "params": { "amount": "265.00" }, "id": 6 } I'd also say you could replicate the GET semantics pretty easily. What REST does that you don't address is forces an API to treat everything as a resource, which can be a good thing, but can also be limiting. In the case of transactional systems I'd agree that REST does sometimes add unnecessary complexity however it's also worth considering how addressing a REST API suddenly changes when the client and server support HTTP2. On 22 January 2017 at 22:39, Roberto Santacroce Martins <r@bravado.com.br> wrote: > Nice article +1 thanks > > Em 22/01/2017 18:24, "Anders Rundgren" <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", >> "@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>> >>> 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> >>> >>> Enjoy! >>> Anders >>> >>> >>> >> >>
Received on Sunday, 22 January 2017 21:08:21 UTC