3 ms·
It's not 100 trips for the same resource, it's 100 round trips for 100 ~different~ resources that are required to construct a page. Cacheing won't help, and
by terra_t 16y ago
It's not 100 trips for the same resource, it's 100 round trips for 100 ~different~ resources that are required to construct a page. Cacheing won't help, and in fact, http caching is one of the #1 obstacles in AJAX programming. People who write AJAX APIs are always using cache-busting methods to make sure that browser caches don't screw up their apps with stale data.
The GET model is acceptable for data access (unless you want to radically reduce round trips -- one answer to this is to "virtualize" the REST model and let an app ask for N chunks of data in one request) however, it's bad for data updates, where you're better off exposing operations that exposing data directly.
Security, for instance, is easier to implement if you expose operations because security rules most frequently govern state transitions: to apply security rules in purist REST, you're always having to write comparisons between the old state and the new state and you've got to test for every single possible thing that could break security, even combinations of things that would be harmless by themselves.
If a security-sensitive operation is exposed as an operation, the implementation of security rules is much more clear.
- brown9-2 16y agoCacheing won't help, and in fact, http caching is one of the #1 obstacles in AJAX programming. People who write AJAX APIs are always using cache-busting methods to make sure that browser caches don't screw up their apps with stale data. Ah, I was referring to caching requests from the webapp producing the web page to the remote services it's consuming, assuming this was the setup - not browser caching.