| Time |
S |
Nick |
Message |
| 00:04 |
|
|
kevinswiber joined #rest |
| 00:19 |
|
|
kevinswiber joined #rest |
| 00:24 |
|
|
kevinswiber joined #rest |
| 00:34 |
|
|
wilmoore joined #rest |
| 01:16 |
|
|
kevinswiber joined #rest |
| 01:19 |
|
|
kevinswi_ joined #rest |
| 01:36 |
|
|
kevinswiber joined #rest |
| 01:42 |
|
|
kevinswiber joined #rest |
| 02:53 |
|
|
wilmoore joined #rest |
| 03:14 |
|
|
fumanchu joined #rest |
| 07:31 |
|
|
_ollie joined #rest |
| 08:02 |
|
|
ph88 joined #rest |
| 08:39 |
|
|
martinfilliau joined #rest |
| 08:51 |
|
|
graste joined #rest |
| 11:39 |
|
|
jcromartie joined #rest |
| 11:39 |
|
|
shrink0r joined #rest |
| 11:51 |
|
|
interop_madness joined #rest |
| 11:52 |
|
interop_madness |
should the response for a HEAD request also contain the Content-Disposition and Content-Type headers as if a GET was issued? |
| 11:53 |
|
_ollie |
I think the spec says HEAD generally only omits the response body, so I'd derive a "yes" from that… |
| 12:00 |
|
pdurbin |
interop_madness: any more thoughts on retention time? |
| 12:01 |
|
interop_madness |
pdurbin, i didn't find anything in the RFCs that lets me hint a desired retention time |
| 12:03 |
|
pdurbin |
bummer |
| 12:52 |
|
|
jcromartie joined #rest |
| 13:08 |
|
|
jcromartie joined #rest |
| 13:32 |
|
|
charlex joined #rest |
| 13:37 |
|
|
shrink0r joined #rest |
| 13:53 |
|
|
kevinswiber joined #rest |
| 14:49 |
|
|
pezra joined #rest |
| 15:00 |
|
|
jcromartie joined #rest |
| 15:00 |
|
|
kevinswiber joined #rest |
| 15:02 |
|
|
kevinswiber joined #rest |
| 15:20 |
|
|
shrink0r joined #rest |
| 15:51 |
|
|
kevinswiber joined #rest |
| 16:00 |
|
|
pezra joined #rest |
| 16:05 |
|
|
kevinswiber joined #rest |
| 16:30 |
|
|
kevinswiber joined #rest |
| 16:33 |
|
|
kevinswiber joined #rest |
| 16:38 |
|
|
nkoza joined #rest |
| 17:13 |
|
|
jcromartie joined #rest |
| 17:31 |
|
|
danfinch joined #rest |
| 17:50 |
|
|
jcromartie joined #rest |
| 17:59 |
|
|
jcromart_ joined #rest |
| 18:22 |
|
|
graste joined #rest |
| 18:24 |
|
|
danizord joined #rest |
| 18:30 |
|
|
shrink0r joined #rest |
| 18:49 |
|
|
pezra joined #rest |
| 19:13 |
|
saml |
hello |
| 19:13 |
|
saml |
i'm making a book |
| 19:14 |
|
saml |
GET /book/1/page/abcde?also-give-me=next,prev does this make sense? |
| 19:14 |
|
saml |
it'll give me next page and previous page as embedded |
| 19:17 |
|
asdf` |
saml, sure, why not |
| 19:17 |
|
saml |
so let's say it's actually a slideshow and editors can rearrange slides |
| 19:17 |
|
saml |
so next,prev will change |
| 19:18 |
|
asdf` |
saml, have you seen the way HAL does it? {"actual": "content goes here", "_links": {"next": {"href":"foo"}}, "_embedded": {"next": {"next":"content goes here"}}} |
| 19:18 |
|
saml |
GET /slides |
| 19:18 |
|
saml |
/things/1 did not change. but /things/1?give-me=next,prev changed |
| 19:19 |
|
asdf` |
(or eh, the uri is the key in the embedded obj, not the rel-name) |
| 19:19 |
|
saml |
because next of /things/1 was /things/2 but now it's /things/100 |
| 19:20 |
|
asdf` |
saml, but /things/1 should change as well; the embedding mechanism shoudldn't be the only way you can learn about the next & prev links |
| 19:20 |
|
asdf` |
because if it was, i don't really see a point in having dynamically-enabled embeds at all. You always want the links |
| 19:21 |
|
saml |
hrm that's true. |
| 19:21 |
|
saml |
but current implementation is that next,prev are quried |
| 19:21 |
|
saml |
not stored in the resource |
| 19:21 |
|
saml |
queried |
| 19:22 |
|
asdf` |
okay, what's the issue, anyway? |
| 19:23 |
|
asdf` |
do you mean caching /1 vs /1?embed=next? |
| 19:23 |
|
saml |
issue is implementing cache |
| 19:23 |
|
saml |
yes |
| 19:23 |
|
saml |
if order changes, i should invalidate /1?embed=next |
| 19:23 |
|
saml |
but not /1 |
| 19:25 |
|
asdf` |
i'd guess you can invalidate /1 as well, i think most of the time clients would request it with the next&prev embedded anyway? and this way it'd probably be easier |
| 19:25 |
|
asdf` |
and then you could add a link to /1 without embeds more easily if you wanted to |
| 19:26 |
|
|
_ollie joined #rest |
| 19:40 |
|
fumanchu |
given a choice between complicated schemes to invalidate related resources versus just fetching them separately and letting HTTP work as designed, I always choose the latter. |
| 19:50 |
|
saml |
also when clients do PUT /images/a.jpg , many of /articles/* need to be cache invalidated because they might use /images/a.jpg (for image credit.. etc) |
| 19:54 |
|
saml |
embedded resources and cache seems to be crazy in general |
| 20:34 |
|
trygvis |
saml: embedding resources is no problem, you just have to choose the weakest caching method of all the embedded resources |
| 20:35 |
|
|
kevinswiber joined #rest |
| 20:35 |
|
saml |
weakest caching method? |
| 20:35 |
|
saml |
oh i see |
| 20:36 |
|
saml |
no i don't see |
| 20:37 |
|
|
kevinswiber joined #rest |
| 20:41 |
|
trygvis |
if you can cache /a for 1 hour, and /b for two hours and /a?inc=b includes /b, it can only be cached for 1 hour |
| 20:41 |
|
trygvis |
if /b is must-revalidate, so must the embedding resource too |
| 20:55 |
|
fumanchu |
if I GET /b at 2pm and then GET /a?inc=b at 2:59, that latter copy of b will be served until 3:59, but if I GET /b at 3:30, it will be served until 4:30? Sounds like a recipe for lots of stale conflicts. |
| 20:59 |
|
|
wilmoore joined #rest |
| 21:02 |
|
fumanchu |
in my experience, it's better to just tell folks "you can include data from b in your response to a, just don't expect it to be authoritative. if you need it to be, fetch /b" |
| 21:23 |
|
|
whartung_ joined #rest |
| 21:33 |
|
|
kevinswiber joined #rest |
| 21:34 |
|
|
kevinswi_ joined #rest |
| 22:40 |
|
|
kevinswiber joined #rest |
| 22:43 |
|
|
kevinswi_ joined #rest |
| 23:24 |
|
|
riddle joined #rest |
| 23:32 |
|
|
asm89 joined #rest |
