4 ms·
If your application is a simple key/value store, then scaling won't be a problem. If it's something more complex, then such simplistic caching models won't work
by paul 18y ago
If your application is a simple key/value store, then scaling won't be a problem. If it's something more complex, then such simplistic caching models won't work.
For example, the FriendFeed api includes a method that fetches multiple feeds at once: http://friendfeed.com/api/feed/user?nickname=paul,bret,jim&format=atom http://friendfeed.com/api/feed/user?nickname=paul,bret,jim&#...
Where should one user PUT their updates such that a simple HTTP cache will know to invalidate that GET? It's not possible. The cache must understand the internals of the system in order to do proper invalidation here.
- gunderson 18y agonot really, the system would only need to keep track of the last updated time of each record and when aggregating them, set the proper etag.
- paul 18y agoRight, that means that you are doing your own cache invalidation (by changing the etag or last modified time), not relying on some magic proxy which watches for PUT and DELETE. That also means that you can use normal HTTP and ignore this REST nonsense.
- gunderson 18y agoFair enough, but the thing I like about REST is the consistent API and (ideally) proper handle of request types via mime type information in the header.
- deleted 18y ago[deleted]