| Newsgroups |
gmane.comp.web.services.rest |
| Message-ID |
<[email protected]> |
--d7Itoxgf1LPYZI357463BFD3EYADJbkxi1rUzV9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
hello michael.
On 2014-05-17, 17:09, Michael Schuerig [email protected]
[rest-discuss] wrote:
>>> The "reactive" buzzword has been conspicuously absent from this
>>> list.
>>> I'll try to fill this much needed gap.
>> haven't really seen it buzzing that much, but if you had to give it at
>> least a little substance, how would you explain what it means? just
>> something that's driven by events rather than clients?
> In the context of RESTful APIs, the interesting (tricky) part appears to
> be is how to make things event-driven. I take this to imply that
> communication over a channel is in general one-way. Clients send events
> to servers (without a reply payload), clients receive events from
> servers.
> For the long story: http://www.reactivemanifesto.org/
wow. this seems to happily combine apples and oranges as well as bacon,
whiskey, and cup cakes. but it sure sounds like a good thing to have in
the end.
>> sounds like websockets (maybe not technically, but as the general
>> idea). to me, REST is on a different level than this plumbing. in the
>> same way as you can do REST and notREST over HTTP, the same probably
>> applies to any of the alternative interaction styles. as you point
>> out, REST has more (and more abstract) constraints than just the
>> protocol that's used.
> I'm not convinced that REST is on a different level. The reason is that
> I think that a persistent connection between client and server counts as
> state that has to be managed by the server for each session. I'm not
> saying that this is bad by itself, it just seems to me not to be in
> keeping with REST tenets. Which, in turn, wouldn't necessarily be a
> problem, either. I'm not interested in passing judgment, but rather in
> understanding how the commandments of REST and reactive interact.
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). to me, what changes
may be a sensor's state, and the question is how to get that information
to consumers. whether you do it by pulling or pushing really does not
change the fact that after doing one or the other, the changed resource
state will be available on the consumer side. it's just that pulling it
has vastly different characteristics in terms of scaling, which is why
the web scales so nicely.
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.
if you're interested to read a bit more, here's a starting point:
http://dret.net/netdret/publications#pau11b
>> not sure i agree that polling or long polling are the only (or best)
>> alternatives. there's quite of stuff to be done in the area that i
>> often refer to as "reverse REST": clients subscribe, and then there's
>> 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). 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.
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 |
--d7Itoxgf1LPYZI357463BFD3EYADJbkxi1rUzV9
Content-Type: text/html; charset=ISO-8859-1
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>hello michael.<br>
<br>
On 2014-05-17, 17:09, Michael Schuerig [email protected] <br>
[rest-discuss] wrote:<br>
>>> The "reactive" buzzword has been conspicuously absent from this<br>
>>> list.<br>
>>> I'll try to fill this much needed gap.<br>
>> haven't really seen it buzzing that much, but if you had to give it at<br>
>> least a little substance, how would you explain what it means? just<br>
>> something that's driven by events rather than clients?<br>
> In the context of RESTful APIs, the interesting (tricky) part appears to<br>
> be is how to make things event-driven. I take this to imply that<br>
> communication over a channel is in general one-way. Clients send events<br>
> to servers (without a reply payload), clients receive events from<br>
> servers.<br>
> For the long story: http://www.reactivemanifesto.org/<br>
<br>
wow. this seems to happily combine apples and oranges as well as bacon, <br>
whiskey, and cup cakes. but it sure sounds like a good thing to have in <br>
the end.<br>
<br>
>> sounds like websockets (maybe not technically, but as the general<br>
>> idea). to me, REST is on a different level than this plumbing. in the<br>
>> same way as you can do REST and notREST over HTTP, the same probably<br>
>> applies to any of the alternative interaction styles. as you point<br>
>> out, REST has more (and more abstract) constraints than just the<br>
>> protocol that's used.<br>
> I'm not convinced that REST is on a different level. The reason is that<br>
> I think that a persistent connection between client and server counts as<br>
> state that has to be managed by the server for each session. I'm not<br>
> saying that this is bad by itself, it just seems to me not to be in<br>
> keeping with REST tenets. Which, in turn, wouldn't necessarily be a<br>
> problem, either. I'm not interested in passing judgment, but rather in<br>
> understanding how the commandments of REST and reactive interact.<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). to me, what changes <br>
may be a sensor's state, and the question is how to get that information <br>
to consumers. whether you do it by pulling or pushing really does not <br>
change the fact that after doing one or the other, the changed resource <br>
state will be available on the consumer side. it's just that pulling it <br>
has vastly different characteristics in terms of scaling, which is why <br>
the web scales so nicely.<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 that <br>
coming up with one that works robustly and in a scalable at web scale so <br>
far hasn't worked. the main reason is that for pull, sources don't need <br>
to know the consumers, whereas for push that state needs to be <br>
maintained, which is expensive.<br>
<br>
if you're interested to read a bit more, here's a starting point:<br>
<br>
http://dret.net/netdret/publications#pau11b<br>
<br>
>> not sure i agree that polling or long polling are the only (or best)<br>
>> alternatives. there's quite of stuff to be done in the area that i<br>
>> often refer to as "reverse REST": clients subscribe, and then there's<br>
>> a push model. there are a variety of push protocols (PuSH, MQTT, APN,<br>
>> C2DM, sMAP) out there, but none so far has taken over the world.<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 practice, <br>
for example across all iOS devices (APN), across all android devices <br>
(C2DM), in building automation scenarios (sMAP), or in large sensor <br>
network settings (MQTT). they all come with different design goals and <br>
constraints, and it seems that you have something specific in mind as <br>
well. as long as you don't better understand the specific constraints of <br>
the scenario you have in mind, picking a solution (or writing down the <br>
requirements for a new one) probably will be hard.<br>
<br>
cheers,<br>
<br>
dret.<br>
<br>
-- <br>
erik wilde | mailto:[email protected] - tel:+1-510-2061079 |<br>
| UC Berkeley - School of Information (ISchool) |<br>
| http://dret.net/netdret http://twitter.com/dret |<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/19647;_ylc=X3oDMTJxNWppNmNuBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjQ3BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQwMDM3NTU0NQ--?act=reply&messageNum=19647">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=X3oDMTJlNW9laHVpBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwMDM3NTU0NQ--" 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=X3oDMTM2M285dmxlBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjQ3BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQwMDM3NTU0NQR0cGNJZAMxOTY0Mw--" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a>
(5)
</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=X3oDMTJlcTJqMDNzBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwMDM3NTU0NQ--" 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=X3oDMTJkbXRudmJsBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDAwMzc1NTQ1" 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=19647/stime=1400375545" 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 -->
--d7Itoxgf1LPYZI357463BFD3EYADJbkxi1rUzV9--