> both of which may be improved on-the-fly (e.g., code-on-demand). It's funny that your'e using this quote to prove your point, when it actually identifies the

> both of which may be improved on-the-fly (e.g., code-on-demand). It's funny that your'e using this quote to prove your point, when it actually identifies the perfect example that you're looking for. Image that we have a relatively "dumb" client that can only understand our media type and follow URLs to the next resource. We already agree that this is useful when you have an intelligent actor (human), so let's move on to the part that your'e interested in: "improved on-the-fly". Let's take our dumb client and add one feature: A Javascript engine. This gives us the "code-on-demand" that Fielding referenced. You can now improve your dumb little client, by adding application logic that can be executed on-the-fly. Your client can now be upgraded to understand new media types, or to change the behavior of interaction with existing media types. And yes, this means the client can be upgraded even when there is no human interaction. Want a real world example? I recently wrote a javascript application that automatically runs a set of comprehensive tests on HTTP requests (and their caching properties) and collects the data. I was able to turn the dumb client into a smarter one (for my purposes). It has a single entry point and programmatically follows many different kinds of links. My tests run on approximately 1 billion clients, and I didn't have to update any client software to make that happen. If I want to check the cache behavior of resources behind my business partner's proxy server, guess what: I can upgrade his client (his browser) on the fly to do the testing for me. Want another real world example? We used javascript in a webview (dumb client) on mobile platforms to create unit tests for some native functionality. Our dumb client happens to have a bridge to the native code on the mobile device. This allows us to write one set of unit tests in javscript and run it on multiple mobile platforms. This is a great example that falls outside of the standard desktop web browser examples. So let's take a look at your example. > In either scenario, the non-human client is just as hard-coded as the other--it's either jumping to external URLs or jumping to internal links. We were smart enough to develop a dumb client that can execute code on demand. Now let's upgrade our client to validate the input fields _before_ POSTing back to the server. Bam, we just improved our client on-the-fly, without modifying the client software. So you may be thinking: But how useful is this to me? If I'm developing a new network-based business analysis tool for my company, it's probably not going to run on 1 billion clients. Do I really need to consider hypermedia as engine state and on-the-fly updates? Well no, of course not, that would be overkill. As Fielding put it: "REST is intended for long-lived network-based applications that span multiple organizations. If you don’t see a need for the constraints, then don’t use them."