Runtime linking in RESTful apps can reduce client-server coupling as the server can tweak the workflow at runtime without completely breaking client apps. Here is one more reason to switch from static pre-published URIs to runtime linking.
Say, you built a cool Web API. Folks are excited about your API are are actively using it. You now have some better ideas, and want to find the effectiveness of some options you have. How do you go about testing the effectiveness of each option before flipping on the big switch?
For consumer-facing web apps, A/B testing provides an effective technique for segmented testing of various design/implementation options. Here is one simple way to build hooks for A/B testing into web pages.
// Embed test variables into links. trackId = createLink(<some ID>, <some test variables>); // Store test variables for later analysis storeTest(trackId, <test variables>); // Render link ... + "&track=" + trackId + "...";
This may produce a URI like the following.
<a href="http://example.org/blahBlah?someParams&track=xyz>...</a>
Subsequently, when a user actives this link, the server can correlate that link to the test variables used. This correlation data forms the basis for post-hoc analysis for A/B and other forms of bucketed testing.
By using runtime linking for Web APIs, i.e., by making them take advantage of the HATEOAS constraint of REST, we can use the same technique for correlating API calls to test variables and conduct A/B testing. That is, when clients are discovering URIs at runtime based on known link relations, servers have a chance to get smarter.
