How to balance chunkiness against chattiness when designing your REST API
Suhas Chatekar

I came here to say largely the same thing a Marvin in the other comment. Much of the advice is in this article is good, but the hashing stuff seems redundant. HTTPS etags not only cover this, but do so more efficiently since a single call is used to check the hash and return the content *only* if it’s changed, reducing the overhead of potentially two separate calls. Additionally a lot of HTTP client libraries have support for this built into the caching layer so the app code doesn’t even have to be aware of it. Even if you don’t want client side caching because the data must always be up to date, you can use a client cache time of zero and the must-revalidate cache setting to force rechecks to the origin sever every time while still using the etag system to reduce bandwidth usage.

I also agree that hypermedia is a requirement of REST as originally published. I sort of disagree that ‘anything else is RPC’, but certainly anything else is only an ‘HTTP API’, not REST.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.