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

On 22 January 2017 at 23:22, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2017-01-22 22:07, Adrian Hope-Bailie wrote:
>
>> 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
>> }
>>
>
> That's right but how would you sign this message?  It seems that I have to
> invent something new anyway.


As you would for REST right?

You can use HTTP Signatures but that's just for the headers. (Which could
include a SRI header at least)


>
>
>
> I'd also say you could replicate the GET semantics pretty easily.
>>
>
> Yes, a GET could return the JSON above.
>
> 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.
>
> My primarily "problem" with REST is simply: Request = HTTP Verb + URI +
> Headers + Payload
> I suggest: Request = Payload
>

Or Request = JSON_RPC.Params :)


>
> The secondary problem is signatures.
>

Could this be solved with HTTP Signatures and SRI?

>
>
>
>> 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.
>
> 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 but I think HTTP Push will be
influential as will the ability to re-use a connection (as I understand
things)

>
>
> Anders
>
>
>> On 22 January 2017 at 22:39, Roberto Santacroce Martins <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>> 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>",
>>           "@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@gm
>> ail.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>>
>>
>>                 Enjoy!
>>                 Anders
>>
>>
>>
>>
>>
>>
>