Gotcha. You're right that I got this wrong, but I think my objection still stands; a peer-to-peer interaction model is still not RESTful.
> Its obviously a problem for every request to navigate from the API root if you have tight latency constraints,
Even in truly RESTful systems, 'every request' wouldn't navigate from the root; the first interaction starts there, but it's not like you keep going back to the root every single time you want to do anything.
> In fact, reducing latency by encouraging cacheability is an explicitly-cited motivation for REST.
On latency and the layered system constraint you have a point.
> Even if it's 'oh they're just two different APIs working together', it's not a singular API, which is what we're talking about here.
I thought we were talking about the utility of REST architecture for the API(s) involved. Obviously, if you have requirements which require two different APIs where the consumers of one API are the providers of the other API, then regardless of architecture, it won't be one API, but that's orthogonal to the architecture appropriate to either or both APIs.
Gotcha. You're right that I got this wrong, but I think my objection still stands; a peer-to-peer interaction model is still not RESTful.
> Its obviously a problem for every request to navigate from the API root if you have tight latency constraints,
Even in truly RESTful systems, 'every request' wouldn't navigate from the root; the first interaction starts there, but it's not like you keep going back to the root every single time you want to do anything.
> In fact, reducing latency by encouraging cacheability is an explicitly-cited motivation for REST.
Absolutely. I was thinking of the 'layered system' constraint. From http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch... :
> The primary disadvantage of layered systems is that they add overhead and latency to the processing of data, reducing user-perceived performance.
You are right that caching helps balance this out, but not everything can be cached; for example, a first-person shooter game would be hard to cache.
> A is a client consuming an API and B is a server providing an API.
Even if it's 'oh they're just two different APIs working together', it's not a singular API, which is what we're talking about here.