- 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