greptilian logo

IRC log for #rest, 2015-05-14

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

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.

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.