Re: Reactive REST
"Michael Schuerig [email protected] [rest-discuss]" <[email protected]> Sun, 18 May 2014 17:02:19 +0200
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <20907465.aOZ2j03pTs@fuchsia> |
--gUGPMgBL0Gka8lgWaHz2wYJ42EkIt5VOtcTf7-F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Saturday 17 May 2014 18:15:13 Erik Wilde [email protected] [rest- discuss] wrote: > i guess i am having trouble with looking at a connection as a resource > with state (unless you talk about network monitoring and management > scenarios, which are an entirely different beast). No, a connection isn't a resource. But keeping a connection open from each client to the server puts a strain on the server. Ideally, a RESTful service is loaded only "dynamically" in the sense that the ("static") number of clients is irrelevant, what counts is the ("dynamic") number of requests per unit of time. My understanding of REST is that this is deliberate and very helpful for scalability. Open connections are a strain on a service even in the absence of any requests. For one thing, a single server can only manage a limited number of open connections at a time. In REST, at least as far as I understand it(!), state is only supposed to figure as transferred resource state; session state is prohibited. My understanding may be wrong and I'm perfectly willing to tone down the RESTful ideal for practical purposes. The point I'm trying to make is purely a matter of classification, ie that I think persistent connections are not RESTful. > but it is entirely possible to envisage that HTTP pull is like UPS > ground and free, whereas there may be UPS overnight which costs a bit > but is faster. if you do that, you get to specify your identifier, and > then (and this is why i call this "reverse REST") you become the > resource to be pushed to, i.e. your resource needs to be known by the > event source. there are tons of PubSub approaches out there, only > that coming up with one that works robustly and in a scalable at web > scale so far hasn't worked. the main reason is that for pull, sources > don't need to know the consumers, whereas for push that state needs > to be maintained, which is expensive. So, is "reverse REST" still RESTful? Yes, the individual push request from server to client probably qualifies. The architecture as a whole probably doesn't. As you write, state needs to be maintained which hinders scalability. A truly RESTful solution would have to do without such state. *I* don't see how that is possible, but that's why I started this discussion. Also, I'd like to repeat that I don't mean not being RESTful, or not being reactive, as some kind of condemnation. Both approaches offer very sensible advice in general, I'm interested in seeing how well they fit together. [...] > >> a push model. there are a variety of push protocols (PuSH, MQTT, > >> APN, > >> C2DM, sMAP) out there, but none so far has taken over the world. > > > > I don't know anything about these models/protocols. Do they work in > > practice at this time? In particular, if the client is a single-page > > application running in a browser? > > these are two very different questions. they work very well in > practice, for example across all iOS devices (APN), across all > android devices (C2DM), in building automation scenarios (sMAP), or > in large sensor network settings (MQTT). OK, I take these as existence proofs that push works in practice. > they all come with different > design goals and constraints, and it seems that you have something > specific in mind as well. as long as you don't better understand the > specific constraints of the scenario you have in mind, picking a > solution (or writing down the requirements for a new one) probably > will be hard. Right now I'm not trying to do anything, I'm first and foremost trying to understand the landscape. As a consequence, my specific questions keep changing. My starting point was the question "What would a 'reactive' and RESTful web application look like from browser through app server to database". Especially when it comes to the communication between browser (or rather JavaScript-client) and app server, I don't see how to reconcile statelessness and event-drivenness. Michael -- Michael Schuerig mailto:[email protected] http://www.schuerig.de/michael/ --gUGPMgBL0Gka8lgWaHz2wYJ42EkIt5VOtcTf7-F Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> </head> <body style="background-color: #fff;"> <span style="display:none"> </span> <!--~-|**|PrettyHtmlStartT|**|-~--> <div id="ygrp-mlmsg" style="position:relative;"> <div id="ygrp-msg" style="z-index: 1;"> <!--~-|**|PrettyHtmlEndT|**|-~--> <div id="ygrp-text" > <p>On Saturday 17 May 2014 18:15:13 Erik Wilde [email protected] [rest-<br> discuss] wrote:<br> <br> > i guess i am having trouble with looking at a connection as a resource<br> > with state (unless you talk about network monitoring and management<br> > scenarios, which are an entirely different beast).<br> <br> No, a connection isn't a resource. But keeping a connection open from <br> each client to the server puts a strain on the server. Ideally, a <br> RESTful service is loaded only "dynamically" in the sense that the <br> ("static") number of clients is irrelevant, what counts is the <br> ("dynamic") number of requests per unit of time. My understanding of <br> REST is that this is deliberate and very helpful for scalability. Open <br> connections are a strain on a service even in the absence of any <br> requests. For one thing, a single server can only manage a limited <br> number of open connections at a time.<br> <br> In REST, at least as far as I understand it(!), state is only supposed <br> to figure as transferred resource state; session state is prohibited.<br> <br> My understanding may be wrong and I'm perfectly willing to tone down the <br> RESTful ideal for practical purposes. The point I'm trying to make is <br> purely a matter of classification, ie that I think persistent <br> connections are not RESTful.<br> <br> > but it is entirely possible to envisage that HTTP pull is like UPS<br> > ground and free, whereas there may be UPS overnight which costs a bit<br> > but is faster. if you do that, you get to specify your identifier, and<br> > then (and this is why i call this "reverse REST") you become the<br> > resource to be pushed to, i.e. your resource needs to be known by the<br> > event source. there are tons of PubSub approaches out there, only<br> > that coming up with one that works robustly and in a scalable at web<br> > scale so far hasn't worked. the main reason is that for pull, sources<br> > don't need to know the consumers, whereas for push that state needs<br> > to be maintained, which is expensive.<br> <br> So, is "reverse REST" still RESTful? Yes, the individual push request <br> from server to client probably qualifies. The architecture as a whole <br> probably doesn't. As you write, state needs to be maintained which <br> hinders scalability.<br> <br> A truly RESTful solution would have to do without such state. *I* don't <br> see how that is possible, but that's why I started this discussion.<br> <br> Also, I'd like to repeat that I don't mean not being RESTful, or not <br> being reactive, as some kind of condemnation. Both approaches offer very <br> sensible advice in general, I'm interested in seeing how well they fit <br> together.<br> <br> [...]<br> > >> a push model. there are a variety of push protocols (PuSH, MQTT,<br> > >> APN,<br> > >> C2DM, sMAP) out there, but none so far has taken over the world.<br> > > <br> > > I don't know anything about these models/protocols. Do they work in<br> > > practice at this time? In particular, if the client is a single-page<br> > > application running in a browser?<br> > <br> > these are two very different questions. they work very well in<br> > practice, for example across all iOS devices (APN), across all<br> > android devices (C2DM), in building automation scenarios (sMAP), or<br> > in large sensor network settings (MQTT). <br> <br> OK, I take these as existence proofs that push works in practice.<br> <br> > they all come with different<br> > design goals and constraints, and it seems that you have something<br> > specific in mind as well. as long as you don't better understand the<br> > specific constraints of the scenario you have in mind, picking a<br> > solution (or writing down the requirements for a new one) probably<br> > will be hard.<br> <br> Right now I'm not trying to do anything, I'm first and foremost trying <br> to understand the landscape. As a consequence, my specific questions <br> keep changing. My starting point was the question "What would a <br> 'reactive' and RESTful web application look like from browser through <br> app server to database". Especially when it comes to the communication <br> between browser (or rather JavaScript-client) and app server, I don't <br> see how to reconcile statelessness and event-drivenness.<br> <br> Michael<br> <br> -- <br> Michael Schuerig<br> mailto:[email protected]<br> http://www.schuerig.de/michael/<br> <br> </p> </div> <!--~-|**|PrettyHtmlStart|**|-~--> <div style="color: #fff; height: 0;">__._,_.___</div> <div style="clear:both"> </div> <table cellspacing=4px style="margin-top: 20px; margin-bottom: 10px; color: #2D50FD;"> <tbody> <tr> <td style="font-size: 12px; font-family: arial; font-weight: bold; padding: 7px 5px 5px;" > <a style="text-decoration: none; color: #2D50FD" href="https://groups.yahoo.com/neo/groups/rest-discuss/conversations/messages/19648;_ylc=X3oDMTJxNzBnMTc4BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjQ4BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQwMDQyNTM0MQ--?act=reply&messageNum=19648">Reply via web post</a> </td> <td>•</td> <td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" > <a href="mailto:[email protected]?subject=Re%3A%20%5Brest-discuss%5D%20Reactive%20REST" style="text-decoration: none; color: #2D50FD;"> Reply to sender </a> </td> <td>•</td> <td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;"> <a href="mailto:[email protected]?subject=Re%3A%20%5Brest-discuss%5D%20Reactive%20REST" style="text-decoration: none; color: #2D50FD"> Reply to group </a> </td> <td>•</td> <td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" > <a href="https://groups.yahoo.com/neo/groups/rest-discuss/conversations/newtopic;_ylc=X3oDMTJlN25qc20wBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwMDQyNTM0MQ--" style="text-decoration: none; color: #2D50FD">Start a New Topic</a> </td> <td>•</td> <td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;color: #2D50FD;" > <a href="https://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/19643;_ylc=X3oDMTM2ZDVqaWRsBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjQ4BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQwMDQyNTM0MQR0cGNJZAMxOTY0Mw--" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a> (6) </td> </tr> </tbody> </table> <div id="megaphoneModule"> <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;"> <div> <div class="feature_intro"> <div style="background-color:white;padding:0px 10px;"> <div class="header" style="margin-right:10px;display:inline-block;width:400px;"> <a rel="nofollow" style="text-decoration:none;" target="_blank" href="https://groups.yahoo.com/neo;_ylc=X3oDMTExc2JuanI3BF9TAzk3MzU5NzE0BGNmMTADQ1AEc2VjA21lZ2FwaG9uZQ--"><div style="font-size:15px;line-height:20px;color:blue;">Just launched ! Link preview on Yahoo Groups</div></a> <div class="snippet" style="margin-top:5px;">Visit your Group on the web, simply paste the link to the article, photo or video you wish to share in the message you are composing.</div> </div> <div style="display:inline-block;vertical-align:top;margin-top:10px;"> <a rel="nofollow" target="_blank" href="http://yahoogroups.tumblr.com/post/85014546066/bye-bye-blue-links-welcome-link-preview" name="lm_btn_url" style="text-decoration:none;"> <input type="button" class="lm-btn" value="Learn more" style="font-size:14px;vertical-align:middle;height:30px;cursor:pointer;margin-bottom:10px;width:100px;background-color:rgb(250, 250, 250);margin-right:10px;" name="lm_btn"> </a> <a rel="nofollow" target="_blank" href="https://groups.yahoo.com/neo;_ylc=X3oDMTExc2JuanI3BF9TAzk3MzU5NzE0BGNmMTADQ1AEc2VjA21lZ2FwaG9uZQ--" name="try_btn_url" style="text-decoration:none;"> <input type="button" class="try-btn" value="Try it now" style="font-size:14px;vertical-align:middle;height:30px;cursor:pointer;margin-bottom:10px;width:100px;background-color:rgb(250, 250, 250);" name="try_btn"> </a> </div> </div> </div> </div> <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;"> </div> <!------- Start Nav Bar ------> <!-- |**|begin egp html banner|**| --> <div id="ygrp-vital" style="background-color: #f2f2f2; font-family: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;"> <span id="vithd" style="font-weight: bold; color: #333; text-transform: uppercase; "><a href="https://groups.yahoo.com/neo/groups/rest-discuss/info;_ylc=X3oDMTJlcTgzamRtBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwMDQyNTM0MQ--" style="text-decoration: none;">Visit Your Group</a></span> <ul style="list-style-type: none; margin: 0; padding: 0; display: inline;"> </ul> </div> <div id="ft" style="font-family: Arial; font-size: 11px; margin-top: 5px; padding: 0 2px 0 0; clear: both;"> <a href="https://groups.yahoo.com/neo;_ylc=X3oDMTJkcDhnYTZ1BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDAwNDI1MzQx" style="float: left;"><img src="http://l.yimg.com/ru/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height="15" width="137" alt="Yahoo! Groups" style="border: 0;"/></a> <div style="color: #747575; float: right;"> • <a href="https://info.yahoo.com/privacy/us/yahoo/groups/details.html" style="text-decoration: none;">Privacy</a> • <a href="mailto:[email protected]?subject=Unsubscribe" style="text-decoration: none;">Unsubscribe</a> • <a href="https://info.yahoo.com/legal/us/yahoo/utos/terms/" style="text-decoration: none;">Terms of Use</a> </div> </div> <br> <!-- |**|end egp html banner|**| --> </div> <!-- ygrp-msg --> <!-- Sponsor --> <!-- |**|begin egp html banner|**| --> <div id="ygrp-sponsor" style="width:160px; float:right; clear:none; margin:0 0 25px 0; background: #fff;"> <!-- Start Recommendations --> <div id="ygrp-reco"> </div> <!-- End Recommendations --> </div> <!-- |**|end egp html banner|**| --> <div style="clear:both; color: #FFF; font-size:1px;">.</div> </div> <img src="http://geo.yahoo.com/serv?s=97359714/grpId=4319255/grpspId=1705701014/msgId=19648/stime=1400425341" width="1" height="1"> <br> <img src="http://y.analytics.yahoo.com/fpc.pl?ywarid=515FB27823A7407E&a=10001310322279&js=no&resp=img&cf10=CP" width="1" height="1"> <div style="color: #fff; height: 0;">__,_._,___</div> <!--~-|**|PrettyHtmlEnd|**|-~--> </body> <!--~-|**|PrettyHtmlStart|**|-~--> <head> <style type="text/css"> <!-- #ygrp-mkp { border: 1px solid #d8d8d8; font-family: Arial; margin: 10px 0; padding: 0 10px; } #ygrp-mkp hr { border: 1px solid #d8d8d8; } #ygrp-mkp #hd { color: #628c2a; font-size: 85%; font-weight: 700; line-height: 122%; margin: 10px 0; } #ygrp-mkp #ads { margin-bottom: 10px; } #ygrp-mkp .ad { padding: 0 0; } #ygrp-mkp .ad p { margin: 0; } #ygrp-mkp .ad a { color: #0000ff; text-decoration: none; } #ygrp-sponsor #ygrp-lc { font-family: Arial; } #ygrp-sponsor #ygrp-lc #hd { margin: 10px 0px; font-weight: 700; font-size: 78%; line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad { margin-bottom: 10px; padding: 0 0; } #actions { font-family: Verdana; font-size: 11px; padding: 10px 0; } #activity { background-color: #e0ecee; float: left; font-family: Verdana; font-size: 10px; padding: 10px; } #activity span { font-weight: 700; } #activity span:first-child { text-transform: uppercase; } #activity span a { color: #5085b6; text-decoration: none; } #activity span span { color: #ff7900; } #activity span .underline { text-decoration: underline; } .attach { clear: both; display: table; font-family: Arial; font-size: 12px; padding: 10px 0; width: 400px; } .attach div a { text-decoration: none; } .attach img { border: none; padding-right: 5px; } .attach label { display: block; margin-bottom: 5px; } .attach label a { text-decoration: none; } blockquote { margin: 0 0 0 4px; } .bold { font-family: Arial; font-size: 13px; font-weight: 700; } .bold a { text-decoration: none; } dd.last p a { font-family: Verdana; font-weight: 700; } dd.last p span { margin-right: 10px; font-family: Verdana; font-weight: 700; } dd.last p span.yshortcuts { margin-right: 0; } div.attach-table div div a { text-decoration: none; } div.attach-table { width: 400px; } div.file-title a, div.file-title a:active, div.file-title a:hover, div.file-title a:visited { text-decoration: none; } div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div.photo-title a:visited { text-decoration: none; } div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts { font-family: Verdana; font-size: 10px; font-weight: normal; } .green { color: #628c2a; } .MsoNormal { margin: 0 0 0 0; } o { font-size: 0; } #photos div { float: left; width: 72px; } #photos div div { border: 1px solid #666666; height: 62px; overflow: hidden; width: 62px; } #photos div label { color: #666666; font-size: 10px; overflow: hidden; text-align: center; white-space: nowrap; width: 64px; } #reco-category { font-size: 77%; } #reco-desc { font-size: 77%; } .replbq { margin: 4px; } #ygrp-actbar div a:first-child { /* border-right: 0px solid #000;*/ margin-right: 2px; padding-right: 5px; } #ygrp-mlmsg { font-size: 13px; font-family: Arial, helvetica,clean, sans-serif; *font-size: small; *font: x-small; } #ygrp-mlmsg table { font-size: inherit; font: 100%; } #ygrp-mlmsg select, input, textarea { font: 99% Arial, Helvetica, clean, sans-serif; } #ygrp-mlmsg pre, code { font:115% monospace; *font-size:100%; } #ygrp-mlmsg * { line-height: 1.22em; } #ygrp-mlmsg #logo { padding-bottom: 10px; } #ygrp-msg p a { font-family: Verdana; } #ygrp-msg p#attach-count span { color: #1E66AE; font-weight: 700; } #ygrp-reco #reco-head { color: #ff7900; font-weight: 700; } #ygrp-reco { margin-bottom: 20px; padding: 0px; } #ygrp-sponsor #ov li a { font-size: 130%; text-decoration: none; } #ygrp-sponsor #ov li { font-size: 77%; list-style-type: square; padding: 6px 0; } #ygrp-sponsor #ov ul { margin: 0; padding: 0 0 0 8px; } #ygrp-text { font-family: Georgia; } #ygrp-text p { margin: 0 0 1em 0; } #ygrp-text tt { font-size: 120%; } #ygrp-vital ul li:last-child { border-right: none !important; } --> </style> </head> <!--~-|**|PrettyHtmlEnd|**|-~--> </html> <!-- end group email --> --gUGPMgBL0Gka8lgWaHz2wYJ42EkIt5VOtcTf7-F--