W3C home > Mailing lists > Public > public-interledger@w3.org > January 2017

Re: A Critical Analysis of REST APIs for "Transaction Systems"

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Sun, 22 Jan 2017 23:07:47 +0200
Message-ID: <CA+eFz_LQ0zOLuAvnk7RmS2XOo7QsdedGPLQS61hWrVVDbyojBg@mail.gmail.com>
To: Roberto Santacroce Martins <r@bravado.com.br>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, Interledger Community Group <public-interledger@w3.org>
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

This archive was generated by hypermail 2.3.1 : Sunday, 22 January 2017 21:08:22 UTC