REST was never about CRUD

Re:REST was never about CRUD by organsnyder on Thursday July 19, 2018 @07:15AM (#17565291)

For caching to work, you need to sit down—ideally with business stakeholders—and decide what the caching policy should be for each data element. For instance, in a healthcare domain, your core patient demographics—name, DOB, ethnicity, gender...—can likely have a fairly long TTL (perhaps even a day or more), since those attributes don't tend to change very often. However, something like a patient's list of upcoming appointments should have a very short TTL, since it changes more frequently.

Once you've made those decisions from a business perspective, you can have your services send the HTTP headers to effect that caching behavior.

[ Parent | on HN ]

Re:REST was never about CRUD by xyzzy123 on Thursday July 19, 2018 @07:45AM (#17565420)

Except for regulatory reasons you will not be able to cache any of those fields you mentioned using standard HTTP infrastructure...

You also probably should not let the browser cache it either (you’ll typically get dinged for it in pentests because your app may be used on a shared computer).

[ Parent | on HN ]

Re:REST was never about CRUD by organsnyder on Thursday July 19, 2018 @07:57AM (#17565452)

You may not be able to present cacheable data to your end-users, but you can still utilize caching for internal consumers (such as application-layer services consuming data from enterprise-layer services).

Or, if you have a CDN, you could cache closer to the end-user (assuming you have the necessary controls on your CDN to meet regulatory [and common-sense] requirements).

[ Parent | on HN ]

Re:REST was never about CRUD by xyzzy123 on Thursday July 19, 2018 @08:06AM (#17565485)

Yep, caching in generally totally makes sense where possible and agree re: services and CDNs.

But end-to-end cacheability at the HTTP layer, part of the original rationale behind the REST API design style, does not make sense for most APIs anymore in 2018.

[ Parent | on HN ]

Re:REST was never about CRUD by mwcampbell on Thursday July 19, 2018 @10:36AM (#17566660)

> But end-to-end cacheability at the HTTP layer, part of the original rationale behind the REST API design style, does not make sense for most APIs anymore in 2018.

Why not? What were the relevant changes between the 90s and 2018?

[ Parent | on HN ]

Re:REST was never about CRUD by xyzzy123 on Thursday July 19, 2018 @06:04PM (#17570742)

* Most APIs are authenticated.

* HTTPS has broken intermediate caches.

* Most responses are personalised or highly dynamic.

* Many responses contain PII or sensitive information and should not be cached.

* Many requests are rate-limited, billed or metered.

Observation: people go out of their way to cache static resources but tend to disable caching entirely on their JSON APIs.

I do have some bias; recovering pentester who rarely worked with APIs that served the same response to all users.

[ Parent | on HN ]

Re:REST was never about CRUD by organsnyder on Friday July 20, 2018 @09:25AM (#17574762)

There are still many use-cases for HTTP caches within internal infrastructure—such as between microservices.

[ Parent | on HN ]

Re:REST was never about CRUD by falcolas on Thursday July 19, 2018 @11:50AM (#17567423)

This depends on downstream caches respecting your TTLs. And, as Java has shown with their DNS implementation, that's not a reasonable expectation to hold.

You can force some of it by putting everything behind TLS, but even then there will be downstream caches for some of your customers (especially the enterprise customers with their sweet, sweet enterprise money) which will still interfere with your expected caching.

[ Parent | on HN ]