4 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. I have just googled a random

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. I have just googled a random service that self-describes its API as REST [2]. I would be glad if someone could pinpoint me at the exact differences that make it "closer to file transfer than RPC". [1] I guess in its original long gone meaning it's something closer to what 90s web looked like, but no one uses it in that sense. [2] https://developers.google.com/fit/rest https://developers.google.com/fit/rest

theamk 4y ago
Here is an example: https://developers.google.com/fit/rest/v1/datasets#get_a_dataset https://developers.google.com/fit/rest/v1/datasets#get_a_dat... It says: "To get a dataset, do HTTP GET to this URL. The result is a JSON document". Notably, this does not _look_ like RPC call -- there is no "getData" anywhere, no {"status": "ok"} field. Instead, this is pretty identical to how you would access a static directory with weirdly-named files. (If you never worked with "static directory with weirly-named files" API, here is an example: ftp://ftp.swpc.noaa.gov/pub/forecasts/45DF/ . To fetch data, you access file named "{MM}{DD}45DF.txt" (via FTP, no less!), get the document and parse. The REST is a modern equivalent of this.) NotablyThis does not sound like a "getData()" function
- LudwigNagasena 4y ago
  Even disregarding the argument that those differences wouldn't warrant the asserted distinction, > there is no "getData" anywhere Here it is: HTTP method GET > no {"status": "ok"} field And here it is: "The response is a 200 OK status code."
  - theamk 4y ago
    Under the same logic, would you call fetching static file "RPC call"? What about fetching a static file via FTP (per my other example) or Gopher -- is this RPC as well? In general, do you think it is possible at all to have a request/response protocol which is _not_ RPC?
    - LudwigNagasena 4y ago
      > Under the same logic, would you call fetching static file "RPC call"? What about fetching a static file via FTP (per my other example) or Gopher -- is this RPC as well? Fetching stuff over FTP, Gopher or HTTP is not RPC per se. Just as merely using classes, or not using classes, doesn't mean that you do or don't adhere to OOP. > In general, do you think it is possible at all to have a request/response protocol which is _not_ RPC? RPC means that you call functions that require remote execution similarly to the way you call local functions. If what you are doing doesn't fit that paradigm semantically, it isn't RPC.
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 ago
  https://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]

theamk 4y ago

Here is an example: https://developers.google.com/fit/rest/v1/datasets#get_a_dataset https://developers.google.com/fit/rest/v1/datasets#get_a_dat... It says: "To get a dataset, do HTTP GET to this URL. The result is a JSON document". Notably, this does not _look_ like RPC call -- there is no "getData" anywhere, no {"status": "ok"} field. Instead, this is pretty identical to how you would access a static directory with weirdly-named files. (If you never worked with "static directory with weirly-named files" API, here is an example: ftp://ftp.swpc.noaa.gov/pub/forecasts/45DF/ . To fetch data, you access file named "{MM}{DD}45DF.txt" (via FTP, no less!), get the document and parse. The REST is a modern equivalent of this.) NotablyThis does not sound like a "getData()" function

LudwigNagasena 4y ago
Even disregarding the argument that those differences wouldn't warrant the asserted distinction, > there is no "getData" anywhere Here it is: HTTP method GET > no {"status": "ok"} field And here it is: "The response is a 200 OK status code."
- theamk 4y ago
  Under the same logic, would you call fetching static file "RPC call"? What about fetching a static file via FTP (per my other example) or Gopher -- is this RPC as well? In general, do you think it is possible at all to have a request/response protocol which is _not_ RPC?
  - LudwigNagasena 4y ago
    > Under the same logic, would you call fetching static file "RPC call"? What about fetching a static file via FTP (per my other example) or Gopher -- is this RPC as well? Fetching stuff over FTP, Gopher or HTTP is not RPC per se. Just as merely using classes, or not using classes, doesn't mean that you do or don't adhere to OOP. > In general, do you think it is possible at all to have a request/response protocol which is _not_ RPC? RPC means that you call functions that require remote execution similarly to the way you call local functions. If what you are doing doesn't fit that paradigm semantically, it isn't RPC.

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 ago
https://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]