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

Adrian is making all good points.

Since this would be a protocol for any and all ledgers, I suggest using
basic technologies.  Could this be done with HTTP only?  The content header
has name value pairs.  And the Content can be anything.

An HTTP message might replace the need for a JSON structure.

Andrew B. Brown
(512) 947-8282
http://KidsCourtyard.com


On Sun, Jan 22, 2017 at 4:07 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
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
> }
>
> 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
>>>>
>>>>
>>>>
>>>
>>>
>