Streamline the REST API

[akaric108]

There are a couple of short-comings in the current REST API that made implementing it very awkward.

I think it would be very natural (because of our elixir backend) if the resources in our API reflect our processes that are running in our app; then our API becomes just a bunch of POST requests with messages (JSON encoded) as the payloads. And these messages would be "acted out" by the process spawned for the client though the authentication process (the address of the process would be encoded in the authentication header of the request)

Thoughts @lupinclaw? I think you initially envisioned something more strict (what I'm proposing is more-or-less RPCon a HTTP/TLS carrier).

[akaric108]

from @lupinclaw:

my original thought was definitely more strict, I dont mind shifting a lot of the computing away from the API handler into the indivdiual processes

i think structuring it like RPC lends itself to the orignal goal of having the backend be scalable accross a distributed server architecture

cuz in theory spawn user and game processes could be running on their own hardware and its connected by message passing

i am hesitant to restructure our API so fully tho, but as long as the front end is agnostic to anything but the JSON obj then ig it doesnt matter too much

[akaric108]

shifting a lot of the computing away from the API handler into the individual processes

Yeah the handler should never be the thing doing the actual computations anyways, regardless of the API it implements.

The job of the handler is solely to handle requests; parsing and unparsing JSON, building the arguments to call functions with, that's all the handler should be doing, again, regardless of the API.

I should clarify that by "strict", I mean instead of doing something like:

$ curl http://127.0.0.1:8080/users/sign_in -X POST -d '{"username": "foo", "password": "bar"}'
#<SESSION_ID>
$

We do something like:

$ curl http://127.0.0.1:8080/users -X POST -d '"sign_in": {"username": "foo", "password": "bar"}'
{":ok", "#<SESSION ID>"}
$

Which would send the message sign_in(%{username: "foo", password: "bar" }) to the Users supervisor, which would spawn a process and return our PID.

I called this "less strict" because you'd have to know that sign_in exists in the backend, but I guess anyone could make the argument that REST API's are no different because we have to know which resources exist, and what type of values they return.

i am hesitant to restructure our API so fully tho,

I'm not because I think this just makes more sense, and because I'll take the blunt of the changes needed to be done to the front-end to shift it over.

It also means we don't have to design two separate APIs anymore (one for the actors, another for the REST), and I'm all for that.

[lupinclaw]

Yes, I like taking the message in and parsing it like that instead of the long endpoint URL per user action.

This also matches the distributed design pattern a lot better.

[akaric108]

Sounds good, I do have a pretty good idea in my head on how I want to implement this thing... I'll give it a go, and then if we like it we can basically forget about the REST API and focus hard on designing the actors and supervision trees.