/// Napkin sketch for HATEOAS optimisation ///
1. CDN serves landing site + client-side controllers
2. client-side controllers react to client-side input, by dynamically manipulating views, from client-side data, when available
3. when client-side data is insufficient, client-side controllers make API calls to get additional assets and/or data from servers, subsequently updating client-side models, and then reiterating step 2.
Local Note : steps 1. and 3. can be implemented with or without edge-computing, with or without server-side rendering.
Global Note :
Based on public debates ( such as this one : https://www.reddit.com/r/programming/comments/w2nwyy/how_did_rest_come_to_mean_the_opposite_of_rest/ ) it seems obvious that at least half the participants have no grasp of Fielding's original thesis defining REST. This provides some motivation for me to produce an annotation of Fielding's thesis in the future.
IMLO : At some point in the early 2000s, it became popular to speak of REST as being opposed to RPC, CORBA, and SOAP. (Let's be clear here : RPC is the end-game in ALL physical information transfers.) CORBA and SOAP were just special-cases of RPC, marketed by specific industry groups (OMG and MSFT respectively) to standardise RPC ergonomics between parties. REST is an approach to implementing RPC, CORBA, SOAP, etc. - which is given by example in HTTP. REST provides a protocol infrastructure to bootstrap communications about RPC, beginning with fundamental protocol interfaces, which MAY BE ESCALATED TO MORE COMPLEX REPRESENTATIONS. The concept of protocol tunneling is included in Fielding's thesis ... and if you can tunnel, then you can basically do anything. As long as you do it a certain way.
No comments :
Post a Comment