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

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.


> 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

The secondary problem is signatures.

>
> 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?

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@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>>
>
>                 Enjoy!
>                 Anders
>
>
>
>
>

Received on Sunday, 22 January 2017 21:23:16 UTC