| Time |
S |
Nick |
Message |
| 00:12 |
|
|
shrink0r_ joined #rest |
| 00:58 |
|
|
arbelos joined #rest |
| 01:21 |
|
|
warehouse13 joined #rest |
| 02:18 |
|
|
shrink0r joined #rest |
| 02:28 |
|
|
baweaver joined #rest |
| 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 |
... |
| 04:14 |
|
|
daxim joined #rest |
| 05:02 |
|
|
shrink0r_ joined #rest |
| 05:04 |
|
|
shrink0r joined #rest |
| 05:44 |
|
|
adaro joined #rest |
| 06:53 |
|
|
Left_Turn joined #rest |
| 07:29 |
|
|
rosstuck joined #rest |
| 08:59 |
|
|
warehouse13 joined #rest |
| 09:57 |
|
|
mezod joined #rest |
| 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 |
| 13:08 |
|
|
angular_mike joined #rest |
| 14:10 |
|
|
foist joined #rest |
| 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:40 |
|
|
baweaver joined #rest |
| 15:43 |
|
|
fumanchu joined #rest |
| 15:51 |
|
pdurbin |
trygvis: this is fanastic. good work |
| 17:21 |
|
|
ModusPwnens joined #rest |
| 17:21 |
|
|
sfisque joined #rest |
| 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 |
|
|
navls joined #rest |
| 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. |
| 18:27 |
|
|
fumanchu_ joined #rest |
| 18:39 |
|
|
fumanchu joined #rest |
| 18:56 |
|
|
shrink0r joined #rest |
| 19:00 |
|
trygvis |
pdurbin: thanks |
| 19:27 |
|
pdurbin |
trygvis: keep up the good work |
| 19:35 |
|
trygvis |
:) |
| 19:57 |
|
|
Left_Turn joined #rest |
| 20:37 |
|
|
sfisque joined #rest |
| 20:40 |
|
|
adaro joined #rest |
| 21:30 |
|
|
arbelos joined #rest |
| 21:34 |
|
|
shrink0r_ joined #rest |
| 21:35 |
|
|
shrink0r joined #rest |
