3 ms·
> I don't know what REST is "really" supposed to mean [1], but every time I saw it used, it basically meant RPC with JSON over HTTP That "basically" is doing a
by naasking 4y ago
> I don't know what REST is "really" supposed to mean [1], but every time I saw it used, it basically meant RPC with JSON over HTTP
That "basically" is doing a lot of work in your claim. Show me the equivalent of idempotency that clients and servers can depend on in any standard RPC spec. If there is no such guarantee, then REST is not RPC.
Certainly you can in some sense mimic REST using RPC per the Turing tarpit, just like you can simulate RPC in REST, but that's not the same as saying REST is RPC.
- pshirshov 4y ago@readonly def readProfile(uid: UserId): UserProfile @total def sum(a: int, b: int): int @pure def traverse(...): I can't enforce any REST "guarantees" but I can do it up to some extent with a custom RPC framework.
- LudwigNagasena 4y agohttps://pubs.opengroup.org/onlinepubs/9629399/chap6.htm#tagtcjh_10 https://pubs.opengroup.org/onlinepubs/9629399/chap6.htm#tagt... > With the RPC communications protocols, a maybe call lacks execution guarantees; an idempotent call, including broadcast, guarantees that the data for an RPC is received and processed zero or more times; and an at-most-once call guarantees that the call data is received and processed at most one time (may be executed partially or zero times). Both idempotent and at-most-once services guarantee that a sequence of calls in a session are processed in the order of invocation by the client.
- deleted 4y ago[deleted]