Re: Reactive REST
"Hubert A Le Van Gong [email protected] [rest-discuss]" <[email protected]> Sun, 18 May 2014 23:55:29 -0700
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_AE87A9E2-A10D-4ECF-8D46-CB4B052888CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Michael, I don't quite follow why you think a permanent HTTP session is against REST= ful principles. Isn't the HTTP session management at a different level (tra= nsport) than the actual resource management and the stateless principles as= sociated to it? In the same vein, would you also consider one cannot define a RESTful servi= ce over persistent HTTPS connections for instance? Best, Hubert On May 18, 2014, at 8:02 AM, Michael Schuerig [email protected] [re= st-discuss] <[email protected]> wrote: > On Saturday 17 May 2014 18:15:13 Erik Wilde [email protected] [rest- > discuss] wrote: >=20 > > 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). >=20 > No, a connection isn't a resource. But keeping a connection open from=20 > each client to the server puts a strain on the server. Ideally, a=20 > RESTful service is loaded only "dynamically" in the sense that the=20 > ("static") number of clients is irrelevant, what counts is the=20 > ("dynamic") number of requests per unit of time. My understanding of=20 > REST is that this is deliberate and very helpful for scalability. Open=20 > connections are a strain on a service even in the absence of any=20 > requests. For one thing, a single server can only manage a limited=20 > number of open connections at a time. >=20 > In REST, at least as far as I understand it(!), state is only supposed=20 > to figure as transferred resource state; session state is prohibited. >=20 > My understanding may be wrong and I'm perfectly willing to tone down the= =20 > RESTful ideal for practical purposes. The point I'm trying to make is=20 > purely a matter of classification, ie that I think persistent=20 > connections are not RESTful. >=20 > > 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. >=20 > So, is "reverse REST" still RESTful? Yes, the individual push request=20 > from server to client probably qualifies. The architecture as a whole=20 > probably doesn't. As you write, state needs to be maintained which=20 > hinders scalability. >=20 > A truly RESTful solution would have to do without such state. *I* don't=20 > see how that is possible, but that's why I started this discussion. >=20 > Also, I'd like to repeat that I don't mean not being RESTful, or not=20 > being reactive, as some kind of condemnation. Both approaches offer very= =20 > sensible advice in general, I'm interested in seeing how well they fit=20 > together. >=20 > [...] > > >> 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. > > >=20 > > > 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? > >=20 > > 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).=20 >=20 > OK, I take these as existence proofs that push works in practice. >=20 > > 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. >=20 > Right now I'm not trying to do anything, I'm first and foremost trying=20 > to understand the landscape. As a consequence, my specific questions=20 > keep changing. My starting point was the question "What would a=20 > 'reactive' and RESTful web application look like from browser through=20 > app server to database". Especially when it comes to the communication=20 > between browser (or rather JavaScript-client) and app server, I don't=20 > see how to reconcile statelessness and event-drivenness. >=20 > Michael >=20 > --=20 > Michael Schuerig > mailto:[email protected] > http://www.schuerig.de/michael/ >=20 >=20 >=20 --Apple-Mail=_AE87A9E2-A10D-4ECF-8D46-CB4B052888CB Content-Type: text/html; charset=windows-1252 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>Hi Michael,<div><br></div><div>I don't quite follow why you think a permanent HTTP session is against RESTful principles. Isn't the HTTP session management at a different level (transport) than the actual resource management and the stateless principles associated to it?</div><div>In the same vein, would you also consider one cannot define a RESTful service over persistent HTTPS connections for instance?</div><div><br></div><div><br></div><div>Best,</div><div>Hubert</div><div><br></div><div><br><div><div>On May 18, 2014, at 8:02 AM, Michael Schuerig <a href="mailto:[email protected]">[email protected]</a> [rest-discuss] <<a href="mailto:[email protected]">[email protected]</a>> wrote:</div><br class="Apple-interchange-newline"><blockquot e type="cite"><div style="font-family: Helvetica;font-size: 12px;font-style: normal;font-variant: normal;font-weight: normal;letter-spacing: normal;text-align: start;text-indent: 0px;text-transform: none;white-space: normal;"><div id="ygrp-mlmsg" style="font-size: 13px;font-family: Arial, helvetica, clean, sans-serif;"><div id="ygrp-msg"><div id="ygrp-text" style="font-family: Georgia;"><p style="margin: 0px 0px 1em;">On Saturday 17 May 2014 18:15:13 Erik Wilde<span class="Apple-converted-space"> </span><a href="mailto:[email protected]" style="font-family: Verdana;">[email protected]</a><span class="Apple-converted-space"> </span>[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 abou t 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<span class="Apple-converted-space"> </span><br>each client to the server puts a strain on the server. Ideally, a<span class="Apple-converted-space"> </span><br>RESTful service is loaded only "dynamically" in the sense that the<span class="Apple-converted-space"> </span><br>("static") number of clients is irrelevant, what counts is the<span class="Apple-converted-space"> </span><br>("dynamic") number of requests per unit of time. My understanding of<span class="Apple-converted-space"> </span><br>REST is that this is deliberate and very helpful for scalability. Open<span class="Apple-converted-sp ace"> </span><br>connections are a strain on a service even in the absence of any<span class="Apple-converted-space"> </span><br>requests. For one thing, a single server can only manage a limited<span class="Apple-converted-space"> </span><br>number of open connections at a time.<br><br>In REST, at least as far as I understand it(!), state is only supposed<span class="Apple-converted-space"> </span><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<span class="Apple-converted-space"> </span><br>RESTful ideal for practical purposes. The point I'm trying to make is<span class="Apple-converted-space"> </span><br>purely a matter of classification, ie that I thi nk persistent<span class="Apple-converted-space"> </span><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<span class="Apple-converted-space"> </span><br>from server to client probably qualifies. The architecture as a whole<span class="Apple-converted-space"> </span><br>probably doesn't. As you write, state needs to be maintained which<span class="Apple-converted-space"> </span><br>hinders scalability.<br><br>A truly RESTful solution would have to do without such state. *I* don't<span class="Apple-converted-space"> </span><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<span class="Apple-converted-space"> </span><br>being reactive, as some kind of condemnation. Both approaches offer very<span class="Apple-converted-space"> </span><br>sensible advice in general, I'm interested in seeing how well they fit<span class="Apple-converted-space"> </span><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>> ><span class="Apple-converted-space"> </span><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>><span class="Apple-converted-space"> </span><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).<span class="Apple-converted-space"> </span><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<span class="Apple-convert ed-space"> </span><br>to understand the landscape. As a consequence, my specific questions<span class="Apple-converted-space"> </span><br>keep changing. My starting point was the question "What would a<span class="Apple-converted-space"> </span><br>'reactive' and RESTful web application look like from browser through<span class="Apple-converted-space"> </span><br>app server to database". Especially when it comes to the communication<span class="Apple-converted-space"> </span><br>between browser (or rather JavaScript-client) and app server, I don't<span class="Apple-converted-space"> </span><br>see how to reconcile statelessness and event-drivenness.<br><br>Michael<br><br>--<span class="Apple-converted-space"> </span><br>Michael Schuerig<br><a href="mail to:[email protected]" style="font-family: Verdana;">mailto:[email protected]</a><br><a href="http://www.schuerig.de/michael/" style="font-family: Verdana;">http://www.schuerig.de/michael/</a><br><br></p></div><div style="color: rgb(255, 255, 255);height: 0px;"></div></div></div></div></blockquote></div><br></div></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/19649;_ylc=X3oDMTJxdHZhYmduBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjQ5BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQwMDQ4MjQ2OQ--?act=reply&messageNum=19649">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=X3oDMTJlNTlqaGpnBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwMDQ4MjQ2OQ--" 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=X3oDMTM2N3N1cGwxBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjQ5BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQwMDQ4MjQ2OQR0cGNJZAMxOTY0Mw--" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a> (7) </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=X3oDMTJlZ2M2ajFkBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwMDQ4MjQ2OQ--" 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=X3oDMTJkcmwwcTVhBF9TAzk3NDc2NTkwBGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDAwNDgyNDY5" 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=19649/stime=1400482469" 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 --> --Apple-Mail=_AE87A9E2-A10D-4ECF-8D46-CB4B052888CB--