As of this writing, this article is only a couple spots away from the front page. It's clearly not front page material, though.<p>Separating a large, complicated task into multiple orthogonal pieces, and assigning each of these pieces to its own component, has been a fundamental part of software engineering for many decades.<p>Separation of concerns is what OO does. Separation of concerns is what UNIX does. Separation of concerns is what TCP/IP does. Separation of concerns is why global variables are considered "bad." Separation of concerns is not a new idea.<p>This jargon-filled, somewhat poorly worded article is merely repeating a fundamental principle that should be obvious to anyone who's ever written any program larger than a couple hundred lines.<p>What is meant by "[the] client is free to have full coherence of server's public domain including all its public API, domain objects and schemata"?<p>"CSDS regards hypermedia an important aspect of REST; it is a semantic web of interconnected resources. Client will have full coherence of the axes of such relationships and can effectively use to navigate the semantic web - since it is part of the public domain. But for it to become the engine of the application is server dominance." These sentences are a long string of big words, but I'm not sure that there's actually anything meaningful in them.<p>Reading this article makes me really wish I had enough karma to downvote.
Surely this is the only sane way to design a REST API? Of course taken to extremes, things can get silly.<p>As I see it, the point of encapsulation is that you don't know what your system might be asked to do next. Keeping things reasonably generic allows you to respond without a major redesign being required.
Keeping the client and server separate is a new thing? Isn't that what most of the world is doing already?<p>Since the purpose of a service is to provide a service, why would you be limiting it to specific clients in the first place?