Yeah, REST is nice for some things, but for normal APIs, you're calling them from a programming language, so calling remote functions (RPC) is very similar conceptually to calling local functions. You might not be able to guess the paths as easily as REST(?) but then again trying to make things REST style doesn't always work out when the things don't allow all the REST verbs or don't fit into a hierarchy, etc.
For serving a filesystem over HTTP REST is great though. And all that caching stuff comes in handy.
From a practical API standpoint though, having two different encodings (GET in url with url parameter encoding, and POST with form encoded or JSON) is a pain and has caused a number of minor bugs and definitely extra work.
Using HTTP is basically a socket for JSON RPC style calls is I think the most straightforward route. In this you have one RPC per request, POST only, with a JSON request body and JSON response. If you use keep-alive it's similar to a socket but can go through some firewalls a bit easier, and has a built-in framing format and metadata thing. Also it works with existing log monitoring tools and frameworks.
For serving a filesystem over HTTP REST is great though. And all that caching stuff comes in handy.
From a practical API standpoint though, having two different encodings (GET in url with url parameter encoding, and POST with form encoded or JSON) is a pain and has caused a number of minor bugs and definitely extra work.
Using HTTP is basically a socket for JSON RPC style calls is I think the most straightforward route. In this you have one RPC per request, POST only, with a JSON request body and JSON response. If you use keep-alive it's similar to a socket but can go through some firewalls a bit easier, and has a built-in framing format and metadata thing. Also it works with existing log monitoring tools and frameworks.