Time  Nick        Message
03:00 spaceone    hm
03:00 spaceone    i can't instruct a server that it should not use chunked transfer encoding
03:01 spaceone    if i use HTTP/1.0 apache just strips out the whole body
03:01 spaceone    ...
10:19 pdurbin     we were looking at that chunked stuff recently
10:28 trygvis     spaceone: a HTTP/1.1 client is expected to understand chunked transfer encoding
10:38 spaceone    trygvis: yes, i know
10:38 spaceone    that's why i switched to HTTP/1.0
10:38 spaceone    (i just want to test my code also without T-E-…)
10:38 spaceone    but seems apache dropped HTTP/1.0 support
10:45 trygvis     hm, can't you request a resource with a known length? Then it will not use chunked but give you a C-L and a response similar to what 1.0 would
10:46 trygvis     I doubt httpd has dropped 1.0 support
10:47 trygvis     it seems that you can force 1.0 with downgrade-1.0; http://httpd.apache.org/docs/2.4/env.html
11:55 pdurbin     spaceone: so you have opinions about http://restcookbook.com ?
11:56 pdurbin     (according to http://irclogs.shortcircuit.net.au/%23circuits/2015-05-01.log.html#t10:51:13 anyway)
11:57 spaceone    trygvis: i don't control the server part here.. it is a PHP script which always does TE=chunked
11:58 spaceone    pdurbin: well, it is a starting point ;)
11:58 trygvis     oh, ok. then bad php!
11:58 pdurbin     spaceone: if you want you can contribute to this new wiki: https://trygvis.io/rest-wiki
11:58 spaceone    pdurbin: yes
11:59 pdurbin     trygvis: we should probably make it clear that a pull request to https://github.com/trygvis/rest-wiki is the way to do so
11:59 spaceone    pdurbin: i don't see any pages there
11:59 pdurbin     I know to click "History" to get there but it's non obvious.
12:00 pdurbin     spaceone: at the moment only the homepage has content: https://github.com/trygvis/rest-wiki/blob/master/index.mdwn
12:00 pdurbin     greenfield!
12:00 spaceone    okay
14:18 trygvis     I just added some notes on contributing and collection+json as a hypermedia
14:20 trygvis     would like to add notes on more hypermedia, I think that would be nice to show to people
15:51 pdurbin     trygvis: this is fanastic. good work
17:21 ModusPwnens How do you model a property of a rest resource that is too expensive to compute every time you get it?
17:22 ModusPwnens do you just require people to make a GET to /resource/{id}/expensive_to_compute_attr?
17:25 fumanchu    yes, make a new resource for just that attribute, and cache the heck out of it if you can
17:29 whartung    when is it supposed to be computed?
17:30 sfisque     aye, just tune the expiry so that you recalc often enough to prevent stale info
17:37 ModusPwnens We can't do cute caching stuff like that because we never know when it needs updating. It's updated by other processes whenever a transaction is created
17:37 ModusPwnens and client's don't always need to see that attribute when they get the resource, so we want to force them to explicitly get it
17:38 ModusPwnens So, how do we reference this computed object in the representation of the resource returned to the client? We have to do that, to make it discoverable, right?
17:41 whartung    if it's so expensive to create, then you should create it when it changes, not when it's requested.
17:41 whartung    so that means some kind of change logic to detect updates, or posting update events someplace to perform the update
17:42 whartung    meanwhile, everyone else simply sees a static resource that changes occasionally, and has the caching headers set properly (minimally honor the last change data/etag)
17:43 navls       Should I return the name of the object in the object? For example if the target was /cars/honda, should I include {"make":"honda", ...} in the response? It seems redundant but allows for the object to be passed around as a complete unit
17:44 asdf`       navls, sure; don't force the client to try and parse your urls for data
17:44 navls       asdf`: I agree, thanks for the advice
17:52 ModusPwnens whartung: That also doesn't work because it changes far more frequently than it's requested. The modifications that change it would also increase the latency of the request, which is not desirable
17:56 ModusPwnens whartung: We also can't have an async process checking for updates due to the requirements of our system. We can't have some resources ever in a pending state, so every change to them needs to be syncronous
18:03 whartung    then your original request to the resource is going to suck. And you have to accept that. When the request is made, it checks whether it's rendered version is "dirty", if it is, it recreates it right then, and sends it to the client.
18:03 whartung    but what I would suggest instead
18:03 whartung    is that you do use an async process
18:03 whartung    that keeps the reosource up to date
18:03 whartung    the resource is never in an "interim" state
18:03 whartung    since the rendered resources are ALWAYS stale (it's just truth).
18:04 whartung    if a resource is being re-created while someone else is asking for it, they simply get the older version. When the new one is done, it replaces it.
18:04 whartung    that's just a simple race condition.
18:04 whartung    and it's no different semantically from them asking for the cached version while the data behind it is being updated,
18:04 whartung    the difference is the window of exposure
18:04 whartung    if you don't mind have the requesters wait for it, then simply recreate it on the fly and cache it.
18:05 whartung    if you do care about request response time, then you have to compromise somewhere, because the wait to create the update resource is non-negotiable.
19:00 trygvis     pdurbin: thanks
19:27 pdurbin     trygvis: keep up the good work
19:35 trygvis     :)