greptilian logo

IRC log for #rest, 2015-05-14

https://trygvis.io/rest-wiki/

| 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

https://trygvis.io/rest-wiki/