Re: Reactive REST
"Philippe Marsteau [email protected] [rest-discuss]" <[email protected]> Tue, 20 May 2014 19:06:02 -0400
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <CAEoHiHx6s8oCoiT12Fv4FJ7kFYQBaH5L=i4DSRtKk-Jf2r55Bg@mail.gmail.com> |
--089e0160c2ba75c7bb04f9dcec18 Content-Type: text/plain; charset=UTF-8 hello Erik, On Tue, May 20, 2014 at 6:40 PM, Erik Wilde <[email protected]> wrote: > hello philippe. > > On 2014-05-19, 6:49 , Philippe Marsteau [email protected] [rest-discuss] > wrote: > >> This being said you certainly can model a pub/sub polling scenario >> within REST constraints. The pushing scenario however do require state >> on the server that belongs to client. Because the client determines >> lifecycle of these "push config" dynamic resources, eg when to delete >> it, that data need to be kept in sync between machines, and handling* >> that extra state breaks statelessness of REST (*handling like in >> auto-expiring subscriptions over time, etc.) >> > > i am not sure how you get to this conclusion. a client subscription to a > service is a resource, and yes, when a service has to manage millions of > client subscriptions, that is not trivial. but it can be implemented, at a > certain cost, and when you're willing to do that, then you have those > subscriptions available to the service, which can then use them to send > push notifications. that is now services such as APN or C2DM work. it's > RESTful, if you model it in a way that a client POSTs a subscription and > can DELETE it when it cancels. I meant that if state persisted on initial request is pre-requisite for subsequent requests, then it would break stateless constraint of REST. If none of the calls make any assumption of any previous context state stored on the server - following initial request, e.g the subscription state - then it remains RESTful. If you model the context to be stored on the server as a resource itself (e.g the subscription resource) it seems RESTful but the state lifecycle depends on client proper interaction implementation. But you're right, this is more a design cost/tradeoff issue than purely a RESTfulness of the system. > > The other technical pb of pub/sub over HTTP are firewalls or related >> network issues. It is not uncommon that clients have firewalls in place >> that let outgoing calls but require IP whitelisting to let calls come >> in. That further reduces scalability of such model (basically each >> client must be seen as a server and vice-versa). The clients costs is >> typically higher than server (clients establish the HTTP connection and >> close them as appropriate for their use cases). This cost is acceptable >> because you usually have many clients for one server. If the server had >> to pay that connection cost (eg to push data), it would be central and >> all clients would deal with a less responsive server as a result. >> > > yes, for back-end m2m scenarios, URI-based push works. but for pushing to > mobile devices, it doesn't, because they are not part of the open internet > (i.e., they don't have a stable public IP address). > > I think we agree. You bring up another reason why PuSH model is not well adapted for Web scalability (Web will be mostly mobile over time). "Don't call me we'll call you" doesn't apply well here. > > Finally, pub/sub model implies a level of trusts normal HTTP app servers >> do not need to have. Blindly connecting to any HTTP endpoint opens to >> security vulnerabilities. The client (subscriber) will typically expect >> some shared secret or key cert exchange, and the server may not be >> willing to blindly post data to unknown locations. >> > > yes, pubsub probably requires some level of trust, and may just be the > "premium" way of getting information from a service. for massive scale > information distribution, pubsub probably really is not a good model, but > for some other scenarios, that may be different. > > > Sure. PuSH "can" be done. But rarely in a scalable way (at least not over HTTP) unless the number of subscribers is low and you tackle/pay the cost of the several design issues mentioned in this thread. > cheers, > > dret. > > -- > erik wilde | mailto:[email protected] - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | > MfG, Phil --089e0160c2ba75c7bb04f9dcec18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm= l4/strict.dtd"> <html> <head> </head> =20 <body style=3D"background-color: #fff;"> <span style=3D"display:none"> </span> <!--~-|**|PrettyHtmlStartT|**|-~--> <div id=3D"ygrp-mlmsg" style=3D"position:relative;"> <div id=3D"ygrp-msg" style=3D"z-index: 1;"> <!--~-|**|PrettyHtmlEndT|**|-~--> <div id=3D"ygrp-text" > =20=20=20=20=20=20 =20=20=20=20=20=20 <p><div dir=3D"ltr">hello Erik,<div class=3D"gmail_extra"><br><div cl= ass=3D"gmail_quote">On Tue, May 20, 2014 at 6:40 PM, Erik Wilde <span dir= =3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank">dret@be= rkeley.edu</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"border-left:1px #ccc solid;">hel= lo philippe.<div class><br> On 2014-05-19, 6:49 , Philippe Marsteau <a href=3D"mailto:[email protected]= m" target=3D"_blank">[email protected]</a> [rest-discuss] wrote:<br> <blockquote class=3D"gmail_quote" style=3D"border-left:1px #ccc solid;"> This being said you certainly can model a pub/sub polling scenario<br> within REST constraints. The pushing scenario however do require state<br> on the server that belongs to client. Because the client determines<br> lifecycle of these "push config" dynamic resources, eg when to de= lete<br> it, that data need to be kept in sync between machines, and handling*<br> that extra state breaks statelessness of REST (*handling like in<br> auto-expiring subscriptions over time, etc.)<br> </blockquote> <br></div> i am not sure how you get to this conclusion. a client subscription to a se= rvice is a resource, and yes, when a service has to manage millions of clie= nt subscriptions, that is not trivial. but it can be implemented, at a cert= ain cost, and when you're willing to do that, then you have those subsc= riptions available to the service, which can then use them to send push not= ifications. that is now services such as APN or C2DM work. it's RESTful= , if you model it in a way that a client POSTs a subscription and can DELET= E it when it cancels.</blockquote> <div><br></div><div>I meant that if state persisted on initial request is p= re-requisite for subsequent requests, then it would break stateless constra= int of REST. If none of the calls make any assumption of any previous conte= xt state stored on the server - following initial request, e.g the subscrip= tion state - then it remains RESTful. If you model the context to be stored= on the server as a resource itself (e.g the subscription resource) it seem= s RESTful but the state lifecycle depends on client proper interaction impl= ementation. But you're right, this is more a design cost/tradeoff issue= than purely a RESTfulness of the system.</div> <blockquote class=3D"gmail_quote" style=3D"border-left:1px #ccc solid;"><di= v class><br> <blockquote class=3D"gmail_quote" style=3D"border-left:1px #ccc solid;"> The other technical pb of pub/sub over HTTP are firewalls or related<br> network issues. It is not uncommon that clients have firewalls in place<br> that let outgoing calls but require IP whitelisting to let calls come<br> in. That further reduces scalability of such model (basically each<br> client must be seen as a server and vice-versa). The clients costs is<br> typically higher than server (clients establish the HTTP connection and<br> close them as appropriate for their use cases). This cost is acceptable<br> because you usually have many clients for one server. If the server had<br> to pay that connection cost (eg to push data), it would be central and<br> all clients would deal with a less responsive server as a result.<br> </blockquote> <br></div> yes, for back-end m2m scenarios, URI-based push works. but for pushing to m= obile devices, it doesn't, because they are not part of the open intern= et (i.e., they don't have a stable public IP address).<div class> <br></div></blockquote><div>I think we agree. You bring up another reason w= hy PuSH model is not well adapted for Web scalability (Web will be mostly m= obile over time). "Don't call me we'll call you" doesn= 9;t apply well here.</div> <blockquote class=3D"gmail_quote" style=3D"border-left:1px #ccc solid;"><di= v class> <br> <blockquote class=3D"gmail_quote" style=3D"border-left:1px #ccc solid;"> Finally, pub/sub model implies a level of trusts normal HTTP app servers<br= > do not need to have. Blindly connecting to any HTTP endpoint opens to<br> security vulnerabilities. The client (subscriber) will typically expect<br> some shared secret or key cert exchange, and the server may not be<br> willing to blindly post data to unknown locations.<br> </blockquote> <br></div> yes, pubsub probably requires some level of trust, and may just be the &quo= t;premium" way of getting information from a service. for massive scal= e information distribution, pubsub probably really is not a good model, but= for some other scenarios, that may be different.<div class=3D"HOEnZb"> <div class=3D"h5"><br> <br></div></div></blockquote><div>Sure. PuSH "can" be done. But r= arely in a scalable way (at least not over HTTP) unless the number of subsc= ribers is low and you tackle/pay the cost of the several design issues ment= ioned in this thread.</div> <div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"border-left:1px= #ccc solid;"><div class=3D"HOEnZb"><div class=3D"h5"> cheers,<br> <br> dret.<br> <br> -- <br> erik wilde | mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a> =C2=A0- =C2=A0tel:<a href=3D"tel:%2B1-510-2061079" va= lue=3D"+15102061079" target=3D"_blank">+1-510-2061079</a> |<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| UC Berkeley =C2=A0- =C2=A0School= of Information (ISchool) |<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| <a href=3D"http://dret.net/netdr= et" target=3D"_blank">http://dret.net/netdret</a> <a href=3D"http://twitter= .com/dret" target=3D"_blank">http://twitter.com/dret</a> |<br> </div></div></blockquote></div><br>MfG,<br clear=3D"all"><div><br></div>Phi= l</div></div> </p> </div> =20=20=20=20=20 <!--~-|**|PrettyHtmlStart|**|-~--> <div style=3D"color: #fff; height: 0;">__._,_.___</div> =20=20=20=20=20=20=20=20=20=20 =20=20 =20 =20=20=20=20 <div style=3D"clear:both"> </div> <div id=3D"fromDMARC" style=3D"margin-top: 10px;"> <hr style=3D"height:2px ; border-width:0; color:#E3E3E3; background= -color:#E3E3E3;"> Posted by: Philippe Marsteau <[email protected]> <hr = style=3D"height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3= E3;"> </div> <div style=3D"clear:both"> </div> <table cellspacing=3D4px style=3D"margin-top: 10px; margin-bottom: 10px= ; color: #2D50FD;"> <tbody> <tr> <td style=3D"font-size: 12px; font-family: arial; font-weight: bo= ld; padding: 7px 5px 5px;" > <a style=3D"text-decoration: none; color: #2D50FD= " href=3D"https://groups.yahoo.com/neo/groups/rest-discuss/conversations/me= ssages/19655;_ylc=3DX3oDMTJxMnFvdWc1BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3J= wc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjU1BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQwMD= YyNzE2Mw--?act=3Dreply&messageNum=3D19655">Reply via web post</a> </td> <td>•</td> <td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p= x 5px;" > <a href=3D"mailto:[email protected]?subject=3DRe%3A%20%5Brest-= discuss%5D%20Reactive%20REST" style=3D"text-decoration: none; color: #2D50F= D;"> Reply to sender </a> </td> <td>•</td> <td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p= x 5px;"> <a href=3D"mailto:[email protected]?subject=3DRe%3A%= 20%5Brest-discuss%5D%20Reactive%20REST" style=3D"text-decoration: none; col= or: #2D50FD"> Reply to group </a> </td> <td>•</td> <td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p= x 5px;" > <a href=3D"https://groups.yahoo.com/neo/groups/rest-discuss/con= versations/newtopic;_ylc=3DX3oDMTJlZGNrMDRoBF9TAzk3MzU5NzE0BGdycElkAzQzMTky= NTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwMDYyNzE2Mw-= -" style=3D"text-decoration: none; color: #2D50FD">Start a New Topic</a> </td> <td>•</td> <td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p= x 5px;color: #2D50FD;" > <a href=3D"https://groups.yahoo.com/neo/groups/= rest-discuss/conversations/topics/19643;_ylc=3DX3oDMTM2NmcyMWs0BF9TAzk3MzU5= NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjU1BHNlYwNmdHI= Ec2xrA3Z0cGMEc3RpbWUDMTQwMDYyNzE2MwR0cGNJZAMxOTY0Mw--" style=3D"text-decora= tion: none; color: #2D50FD;">Messages in this topic</a> (13) </td> </tr> </tbody> </table> =20=20=20=20=20=20=20=20 <!------- Start Nav Bar ------> =20 <!-- |**|begin egp html banner|**| --> <div id=3D"ygrp-vital" style=3D"background-color: #f2f2f2; font-family: Ver= dana; font-size: 10px; margin-bottom: 10px; padding: 10px;"> <span id=3D"vithd" style=3D"font-weight: bold; color: #333; text-transf= orm: uppercase; "><a href=3D"https://groups.yahoo.com/neo/groups/rest-discu= ss/info;_ylc=3DX3oDMTJlZnIwOXJkBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJ= ZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwMDYyNzE2Mw--" style=3D"= text-decoration: none;">Visit Your Group</a></span> <ul style=3D"list-style-type: none; margin: 0; padding: 0; display: in= line;"> </ul> </div> <div id=3D"ft" style=3D"font-family: Arial; font-size: 11px; margin-top: 5p= x; padding: 0 2px 0 0; clear: both;"> <a href=3D"https://groups.yahoo.com/neo;_ylc=3DX3oDMTJkNmtrNGZsBF9TAzk3ND= c2NTkwBGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzd= GltZQMxNDAwNjI3MTYz" style=3D"float: left;"><img src=3D"http://l.yimg.com/r= u/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height=3D"15"= width=3D"137" alt=3D"Yahoo! Groups" style=3D"border: 0;"/></a> <div style=3D"color: #747575; float: right;"> • <a href=3D"https://i= nfo.yahoo.com/privacy/us/yahoo/groups/details.html" style=3D"text-decoratio= n: none;">Privacy</a> • <a href=3D"mailto:rest-discuss-unsubscribe@yah= oogroups.com?subject=3DUnsubscribe" style=3D"text-decoration: none;">Unsubs= cribe</a> • <a href=3D"https://info.yahoo.com/legal/us/yahoo/utos/term= s/" style=3D"text-decoration: none;">Terms of Use</a> </div> </div> <br> <!-- |**|end egp html banner|**| --> </div> <!-- ygrp-msg --> =20 <!-- Sponsor --> <!-- |**|begin egp html banner|**| --> <div id=3D"ygrp-sponsor" style=3D"width:160px; float:right; clear:none; m= argin:0 0 25px 0; background: #fff;"> <!-- Start Recommendations --> <div id=3D"ygrp-reco"> </div> <!-- End Recommendations --> </div> <!-- |**|end egp html banner|**| --> <div style=3D"clear:both; color: #FFF; font-size:1px;">.</div> </div> <img src=3D"http://geo.yahoo.com/serv?s=3D97359714/grpId=3D4319255/grpspI= d=3D1705701014/msgId=3D19655/stime=3D1400627163" width=3D"1" height=3D"1"> = <br> <img src=3D"http://y.analytics.yahoo.com/fpc.pl?ywarid=3D515FB27823A7407E&a= =3D10001310322279&js=3Dno&resp=3Dimg" width=3D"1" height=3D"1">=20 <div style=3D"color: #fff; height: 0;">__,_._,___</div> <!--~-|**|PrettyHtmlEnd|**|-~--> </body> <!--~-|**|PrettyHtmlStart|**|-~--> <head> <style type=3D"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; } =20=20 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.fi= le-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; }=20 #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;=20 }=20 --> </style> </head> <!--~-|**|PrettyHtmlEnd|**|-~--> </html> <!-- end group email --> --089e0160c2ba75c7bb04f9dcec18--