| Time |
S |
Nick |
Message |
| 00:10 |
|
|
mgomezch joined #rest |
| 00:17 |
|
|
akurilin2 joined #rest |
| 01:15 |
|
|
tmoore joined #rest |
| 01:39 |
|
|
akurilin2 joined #rest |
| 03:07 |
|
|
blahdeblah joined #rest |
| 03:22 |
|
|
wsiqueir joined #rest |
| 03:28 |
|
|
baweaver joined #rest |
| 06:58 |
|
|
Left_Turn joined #rest |
| 08:39 |
|
|
quimrstorres joined #rest |
| 08:40 |
|
|
quimrstorres joined #rest |
| 09:44 |
|
|
mezod joined #rest |
| 09:49 |
|
|
rosstuck joined #rest |
| 10:45 |
|
|
dEPy joined #rest |
| 11:41 |
|
|
_ollie joined #rest |
| 11:56 |
|
|
_ollie joined #rest |
| 12:05 |
|
|
eschmidbauer joined #rest |
| 12:42 |
|
|
fumanchu joined #rest |
| 13:35 |
|
|
quimrstorres joined #rest |
| 13:42 |
|
|
nkoza joined #rest |
| 13:42 |
|
|
travelr joined #rest |
| 13:42 |
|
travelr |
So do we still REST or did we give up |
| 13:43 |
|
|
quimrstorres joined #rest |
| 13:44 |
|
travelr |
guess later |
| 13:44 |
|
travelr |
latter... |
| 13:47 |
|
pdurbin |
travelr: maybe in v2 of our api :) |
| 14:24 |
|
|
wsiqueir joined #rest |
| 14:53 |
|
|
eschmidbauer left #rest |
| 15:01 |
|
|
_ollie joined #rest |
| 15:05 |
|
|
mgomezch joined #rest |
| 15:14 |
|
|
angular_mike_ joined #rest |
| 15:29 |
|
|
ReScO joined #rest |
| 15:29 |
|
ReScO |
hey people |
| 15:36 |
|
pdurbin |
ReScO: hey |
| 15:40 |
|
trygvis |
hello |
| 15:59 |
|
|
quimrstorres joined #rest |
| 16:02 |
|
|
sfisque joined #rest |
| 16:42 |
|
|
baweaver joined #rest |
| 17:08 |
|
|
_ollie joined #rest |
| 18:08 |
|
|
akurilin joined #rest |
| 18:26 |
|
|
akurilin3 joined #rest |
| 19:27 |
|
|
mezod_ joined #rest |
| 20:01 |
|
|
sfisque1 joined #rest |
| 20:05 |
|
|
akurilin joined #rest |
| 21:57 |
|
|
sfisque joined #rest |
| 22:54 |
|
|
fuzzyhorns joined #rest |
| 22:55 |
|
fuzzyhorns |
is hateos incompatible with mobile? |
| 22:55 |
|
fuzzyhorns |
sorry hateoas* |
| 22:55 |
|
fuzzyhorns |
given mobile wants only a single big request |
| 22:55 |
|
fuzzyhorns |
rather than a request/response cycle? |
| 22:57 |
|
fumanchu |
HTTP reliance on caching for network efficiency has always meant fewer, larger messages are better than lots of small ones. That's just exacerbated on mobile. |
| 22:57 |
|
fuzzyhorns |
"high latency for requests means that traversing hypermedia links across the API space is untenable." |
| 22:57 |
|
fuzzyhorns |
https://news.ycombinator.com/item?id=2560648 |
| 22:58 |
|
fuzzyhorns |
fumanchu: except that i think of hateoas as meaning you need to traverse links |
| 22:58 |
|
fumanchu |
right, so avoid traversing links across the network and hit your cache as often as you can |
| 22:58 |
|
fuzzyhorns |
that makes some sense |
| 22:58 |
|
fuzzyhorns |
where does that logic live though? |
| 22:58 |
|
fumanchu |
logic? |
| 22:59 |
|
fumanchu |
it's inherent in the design of your resource boundaries |
| 22:59 |
|
fuzzyhorns |
mm, i mean more, how does a client know to navigate to the cache first? |
| 23:00 |
|
sfisque |
it shouldnt. that's a fabric impl aspect |
| 23:00 |
|
fumanchu |
all requests go through the cache. the server needs to mark its responses as cacheable |
| 23:00 |
|
fuzzyhorns |
so it is just the browsers responsibility essentially? |
| 23:00 |
|
fumanchu |
browser as a kind of user-agent, yes |
| 23:01 |
|
fuzzyhorns |
i guess what i see in conflict is the evolvablity of an api without those smaller requests |
| 23:01 |
|
fuzzyhorns |
but i guess it comes down to cache control |
| 23:01 |
|
fumanchu |
yep |
| 23:02 |
|
sfisque |
but that's not a rest concept. reduction of round tripping has always been an issue, whether rest or not |
| 23:03 |
|
sfisque |
i guess you could say rest exacerbates it (as mentioned) by its design |
| 23:03 |
|
fuzzyhorns |
well, i guess where i approached it from was thinking about the request response cycle with self-descriptive messages as being very nice |
| 23:04 |
|
fuzzyhorns |
because at any time you can just change next message and then change the control flow of the application, and it wont break the client |
| 23:04 |
|
fumanchu |
I didn't say that, but ok |
| 23:04 |
|
fumanchu |
mobile exacerbates it, not rest |
| 23:04 |
|
fuzzyhorns |
yeah i would say mobile does? |
| 23:05 |
|
fuzzyhorns |
i would think rest, imho, doesnt necessarily have an opinion about your request amount |
| 23:05 |
|
sfisque |
rest wouldnt, no, but the underlying fabric to support it would |
| 23:05 |
|
sfisque |
aka SLA, bandwidth, etc. |
| 23:06 |
|
fumanchu |
it does have an opion, actually |
| 23:06 |
|
fumanchu |
opinion |
| 23:07 |
|
fuzzyhorns |
fumanchu: which is what do oyu think? |
| 23:07 |
|
fumanchu |
"For a distributed hypermedia system, component interactions consist of *large-grain* data transfers rather than computation-intensive tasks" (emphasis mine) |
| 23:07 |
|
fumanchu |
in the "Conclusions" of Fielding's dissertation |
| 23:08 |
|
fuzzyhorns |
fumanchu: nice |
| 23:08 |
|
fuzzyhorns |
but what would a computation-intensive task even mean? |
| 23:08 |
|
fuzzyhorns |
how would components interact except via data transfers? |
| 23:08 |
|
sfisque |
small incremental deltas |
| 23:08 |
|
fuzzyhorns |
sorry for my ignorance here |
| 23:09 |
|
fuzzyhorns |
large data transfer is not the opposite of a computation-intensive task is what i mean, sfisque |
| 23:09 |
|
sfisque |
basically batch up your changes and do a single POST/PUT rather than lots of incremental POST/PUTS |
| 23:09 |
|
fuzzyhorns |
or at least not in an obvous way to me |
| 23:09 |
|
sfisque |
aye,i was offering one example |
| 23:09 |
|
fuzzyhorns |
sfisque: what do you think "computation-intensive task" means? |
| 23:10 |
|
fumanchu |
it means that, since the components are distributed, they can't operate in concert on e.g. shared memory |
| 23:10 |
|
sfisque |
anything that requires processing power (even a single transactional boundary demarcation can be intensive) |
| 23:11 |
|
fuzzyhorns |
fumanchu: yeah that makes sense to me |
| 23:11 |
|
fuzzyhorns |
fumanchu: does he further define "large grain" anywhere? |
| 23:11 |
|
sfisque |
a single update to a db table can be intensive if it causes lots of triggers/re-indexing/etc. |
| 23:11 |
|
fumanchu |
oh yes, just search the PDF. 4.1.3 for example |
| 23:11 |
|
fuzzyhorns |
i only know a link that has separate pages |
| 23:11 |
|
sfisque |
compute-intensive doesnt just mean "crunch lots of numbers" |
| 23:12 |
|
fuzzyhorns |
not the whole thing -_- |
| 23:12 |
|
fumanchu |
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf |
| 23:13 |
|
fuzzyhorns |
i wish there was a straight port to html fumanchu |
| 23:13 |
|
fuzzyhorns |
kinda ironic lol |
| 23:13 |
|
fuzzyhorns |
this is what i use: https://www.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.htm#sec_4_3 |
| 23:13 |
|
sfisque |
searchbot google fielding rest whitepaper link |
| 23:13 |
|
searchbot |
sfisque: Fielding Dissertation: CHAPTER 5: Representational State Transfer ...: <https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm>; Roy Fielding - Wikipedia, the free encyclopedia: <http://en.wikipedia.org/wiki/Roy_Fielding>; RESTful Web Processing Service - Agile: <http://www.agile-online.org/Conference_Paper/CDs/agile_2011/contents/pdf/shortpapers/sp_137.pdf>; Untangled - Roy (2 more messages) |
| 23:13 |
|
sfisque |
thanks searchbot |
| 23:13 |
|
* sfisque |
tosses searchbot a cookie |
| 23:13 |
|
fuzzyhorns |
sfisque: yep you found the one you cant search across the entire document of :d |
| 23:17 |
|
fuzzyhorns |
the tension ive seen at work |
| 23:17 |
|
fuzzyhorns |
is between just sending a huge blob of json (nesting resources in resources etc) |
| 23:18 |
|
fuzzyhorns |
and using include params or links to related resources |
| 23:18 |
|
fuzzyhorns |
if there is a related resource and i dont want the network to make roundtrips, is the huge blob of nested stuff my best option? |
| 23:19 |
|
fuzzyhorns |
thoughts on that, fumanchu or sfisque? |
| 23:21 |
|
fumanchu |
I suppose there's always sneakernet as a third option |
| 23:23 |
|
fumanchu |
and of course, HTTP 2 was...eh..."designed" (I use the term loosely) to let you mash together related resources in the same "request" |
| 23:23 |
|
fuzzyhorns |
fumanchu: thats not very reassuring lol |
| 23:23 |
|
fuzzyhorns |
to me it seems like i cant find an answer from any of the rest peeps on this when i try to figure it out |
| 23:24 |
|
fuzzyhorns |
ill be back around later :) |
| 23:24 |
|
fuzzyhorns |
ty for tlaking with me |
| 23:47 |
|
sfisque |
lol missed him |
| 23:47 |
|
sfisque |
oh well |
| 23:48 |
|
sfisque |
i was going to say that maybe what they are trying to achieve doesnt fit rest. too often lately i see systems converted to rest where they should have remained what they were and just integrated into the greater fabric rather than square peg -> round hole |
| 23:48 |
|
sfisque |
not every model fits rest and it will be fun to see what happens a couple years from now when people wake up and start to understand that it's just part of the whole solution |
| 23:51 |
|
sfisque |
model in this sense is "enterprise module" whether its a CRUD factory, message bus, service enabler, etc. |
| 23:51 |
|
fumanchu |
indeed |
| 23:56 |
|
travelr |
sfisque: I'd be very curious to learn more about your experience and why those wouldn't fit REST |
| 23:57 |
|
sfisque |
define "those" |
| 23:58 |
|
travelr |
sfisque: my personal approach is to respect HTTP but lay out more or less traditional RPC calls on top of it, I can tunnel through various media, not just HTTP, so for ex.: /object-type;entity-id/method-name/ and then the form is named parameters and response in JSON |
| 23:58 |
|
travelr |
maps to: objectRepo.get(entityId).methodName(formFields) |
| 23:58 |
|
travelr |
I like when things map on their own. |
