| Newsgroups |
gmane.comp.web.services.rest |
| Message-ID |
<[email protected]> |
--68v-ZZ-Y2wng3oNpBUACuJIhV-8iVCCSG4R9ilB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
hello michael.
On 2014-05-18, 8:02 , Michael Schuerig [email protected]
[rest-discuss] wrote:
> On Saturday 17 May 2014 18:15:13 Erik Wilde [email protected] [rest-
> discuss] wrote:
> 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.
HTTP has persistent connections and that's perfectly fine. because it's
orthogonal to the *interactions*. what would be bad would be if the
persistent connection established some context that was necessary for
the individual interactions. what is not a problem at all is to keep the
TCP connection open and have multiple HTTP interactions across it,
because that saves networking resources, and reusing the TCP connection
is just an optimization.
how connections are managed really is not so much a concern for the
HTTP/REST perspective. it just has to be done in a way that system
design does not depend on established session state.
>> 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.
it just makes things more expensive, and depending on what you're trying
to achieve, you might be willing to pay this cost, or not. introducing
subscribers as resources certainly changes the picture and affects
scalability quite a bit, but that does not mean that the resulting
design is not RESTful anymore. as long as interactions are
resource-oriented and stateless, and resource representations are using
hypermedia, all is well.
> 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.
http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons might
be interesting to read, and looks at similar issues. but it also makes
some assumptions, such as that the service compiling this "here is what
changed" list access to this information somehow.
> 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.
it's a good question and one that probably will become increasingly
important, the more real-time information sources (such as sensors) we
have, and the more we have apps that want to consume this information.
personally, i don't think there's an easy answer here, it all depends on
the scenario.
for example, on http://tiledfeeds.yimingliu.com/ we propose an
architecture where we aggregate resources spatially, and then build a
(pull-oriented) delivery architecture on top of that. that works well if
and only if your resources are spatially distributed. and if you feel
like it, you could still PuSH-enable those tiled feeds, but then you'd
run into the "subscriber management cost" issue mentioned above.
if you don't want/need push, you can simply start reading
http://geofeeds.org/earthquakes/02301021.xml, refresh your copy
occasionally, and you'll get all the information about major earthquakes
in california (which right now will never change, because this is a
static demo and not connected to a live feed of earthquake data).
cheers,
dret.
--68v-ZZ-Y2wng3oNpBUACuJIhV-8iVCCSG4R9ilB
Content-Type: text/html; charset=UTF-8
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-18, 8:02 , Michael Schuerig [email protected] <br>
[rest-discuss] wrote:<br>
> On Saturday 17 May 2014 18:15:13 Erik Wilde [email protected] [rest-<br>
> discuss] wrote:<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>
HTTP has persistent connections and that's perfectly fine. because it's <br>
orthogonal to the *interactions*. what would be bad would be if the <br>
persistent connection established some context that was necessary for <br>
the individual interactions. what is not a problem at all is to keep the <br>
TCP connection open and have multiple HTTP interactions across it, <br>
because that saves networking resources, and reusing the TCP connection <br>
is just an optimization.<br>
<br>
how connections are managed really is not so much a concern for the <br>
HTTP/REST perspective. it just has to be done in a way that system <br>
design does not depend on established session state.<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>
> 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>
it just makes things more expensive, and depending on what you're trying <br>
to achieve, you might be willing to pay this cost, or not. introducing <br>
subscribers as resources certainly changes the picture and affects <br>
scalability quite a bit, but that does not mean that the resulting <br>
design is not RESTful anymore. as long as interactions are <br>
resource-oriented and stateless, and resource representations are using <br>
hypermedia, all is well.<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>
http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons might <br>
be interesting to read, and looks at similar issues. but it also makes <br>
some assumptions, such as that the service compiling this "here is what <br>
changed" list access to this information somehow.<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>
it's a good question and one that probably will become increasingly <br>
important, the more real-time information sources (such as sensors) we <br>
have, and the more we have apps that want to consume this information. <br>
personally, i don't think there's an easy answer here, it all depends on <br>
the scenario.<br>
<br>
for example, on http://tiledfeeds.yimingliu.com/ we propose an <br>
architecture where we aggregate resources spatially, and then build a <br>
(pull-oriented) delivery architecture on top of that. that works well if <br>
and only if your resources are spatially distributed. and if you feel <br>
like it, you could still PuSH-enable those tiled feeds, but then you'd <br>
run into the "subscriber management cost" issue mentioned above.<br>
<br>
if you don't want/need push, you can simply start reading <br>
http://geofeeds.org/earthquakes/02301021.xml, refresh your copy <br>
occasionally, and you'll get all the information about major earthquakes <br>
in california (which right now will never change, because this is a <br>
static demo and not connected to a live feed of earthquake data).<br>
<br>
cheers,<br>
<br>
dret.<br>
</p>
</div>
<!--~-|**|PrettyHtmlStart|**|-~-->
<div style="color: #fff; height: 0;">__._,_.___</div>
<div style="clear:both"> </div>
<div id="fromDMARC" style="margin-top: 10px;">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
Posted by: Erik Wilde <[email protected]> <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>
<div style="clear:both"> </div>
<table cellspacing=4px style="margin-top: 10px; 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/19653;_ylc=X3oDMTJxcjEycTJpBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjUzBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQwMDYyNTIxMw--?act=reply&messageNum=19653">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=X3oDMTJlNzJsZ3ZoBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwMDYyNTIxMw--" 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=X3oDMTM2bWZ1MG5mBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjUzBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQwMDYyNTIxMwR0cGNJZAMxOTY0Mw--" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a>
(11)
</td>
</tr>
</tbody>
</table>
<!------- 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=X3oDMTJlZXNqOWxmBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwMDYyNTIxMw--" 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=X3oDMTJkNXVqNmp0BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDAwNjI1MjEz" 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=19653/stime=1400625213" width="1" height="1"> <br>
<img src="http://y.analytics.yahoo.com/fpc.pl?ywarid=515FB27823A7407E&a=10001310322279&js=no&resp=img" 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 -->
--68v-ZZ-Y2wng3oNpBUACuJIhV-8iVCCSG4R9ilB--