| Time |
S |
Nick |
Message |
| 00:04 |
|
|
fuzzyhorns joined #rest |
| 01:09 |
|
|
fumanchu_ joined #rest |
| 02:45 |
|
|
baweaver joined #rest |
| 03:09 |
|
|
fumanchu joined #rest |
| 03:28 |
|
|
fuzzyhorns joined #rest |
| 03:56 |
|
|
fumanchu_ joined #rest |
| 06:31 |
|
|
baweaver joined #rest |
| 07:18 |
|
|
Left_Turn joined #rest |
| 07:48 |
|
|
graste joined #rest |
| 09:17 |
|
|
quimrstorres joined #rest |
| 09:21 |
|
|
quimrstorres joined #rest |
| 09:36 |
|
|
interop_madness joined #rest |
| 10:39 |
|
|
quimrstorres joined #rest |
| 11:43 |
|
|
Coldblackice_ joined #rest |
| 12:04 |
|
|
prologic joined #rest |
| 12:05 |
|
|
Guest8032 joined #rest |
| 12:27 |
|
|
prologic joined #rest |
| 13:23 |
|
|
quimrstorres joined #rest |
| 14:07 |
|
|
GutPunch joined #rest |
| 14:08 |
|
GutPunch |
when would I use a pagination section in my return, over asking a client to send me a "since_id" and "count" parameter when they want older data ? |
| 14:11 |
|
trygvis |
getting your client to follow the "next" rel would be the most restful |
| 14:14 |
|
GutPunch |
Best in practice? I'm quite new to the more nitty gritty of REST, I had a look over Twitter's API docs and they use the parameter way |
| 14:15 |
|
GutPunch |
well, best in practice is subjective, most commonly encountered I suppose is a better question? |
| 14:16 |
|
trygvis |
the last time I looked at the twitter API it wasn't much restful at all so I wouldn't compare stuff that tries to follow the rest style to twitter's api |
| 14:17 |
|
asdf` |
(i'm not sure i'd say 'RESTful' is 'commonly encountered') |
| 14:17 |
|
asdf` |
(but yeah following links is the gist of it) |
| 14:18 |
|
trygvis |
this is #rest and we pretend that the world is restful :) |
| 14:18 |
|
trygvis |
media types like atom, hal and collection+json all support link relations so with them it would be very natural to use "next" |
| 14:18 |
|
pdurbin |
the github api has "next" rel links |
| 14:19 |
|
GutPunch |
Okay, I should get a grip on coding around rel links either way I suppose |
| 14:19 |
|
GutPunch |
thanks all |
| 15:07 |
|
|
foist joined #rest |
| 16:45 |
|
|
fumanchu joined #rest |
| 16:52 |
|
|
baweaver joined #rest |
| 17:24 |
|
whartung |
anyone have any opinions on etag vs last-modified? |
| 17:24 |
|
whartung |
we need to do some optimistic locking, and I was going to just go with Etags. |
| 17:26 |
|
fumanchu |
prefer etags if you can. the code is simpler on both sides. |
| 17:27 |
|
whartung |
that's what I was thinking |
| 17:31 |
|
whartung |
so, what do you think about optimistic locking. Do you thinkit's worth the effort to fetch a resrouce, then change it, and then just shove it back hoping the etags match, or do you think it's at all worth while to do a HEAD on the resource to see if the etag check might fail before shipping up the entire thing? |
| 17:31 |
|
whartung |
there's still a race condition with the HEAD, but it might save some traffic on a slow moving resource. .. I dunno |
| 17:32 |
|
whartung |
we're mostly using etags for the locking aspect, not for caching. (but we can use it for caching) |
| 17:34 |
|
fumanchu |
it's never worthwhile to look before you leap since you end up having to code the failure mode anyway *plus* your LBYL code |
| 17:34 |
|
whartung |
yea |
| 17:34 |
|
whartung |
ok |
| 17:34 |
|
whartung |
sounds good to me |
| 17:39 |
|
whartung |
just trying to come up with some standards for implementing OL. |
| 18:00 |
|
|
quimrstorres joined #rest |
| 19:12 |
|
|
wsiqueir joined #rest |
| 20:20 |
|
sfisque |
whartung : i would just mimic what jpa does, let the client just submit and the server can respond with either success or report back to the client that they have a stale version. they can then handle however they want to merge "what they have" with "what the server has" |
| 20:21 |
|
sfisque |
though, i'm curious what return code would be "standard" or "expected" for a OL failure |
| 20:21 |
|
whartung |
yea, that's what I would do -- need to look up the proper result code, but essentially: PUT /thing ETag: 123 {thing} |
| 20:22 |
|
whartung |
409 Conflict maybe |
| 20:22 |
|
whartung |
taht's more specific than a generic: 412 Precondition Failed |
| 20:23 |
|
sfisque |
yah, i think we use 409 for things like that |
| 20:23 |
|
whartung |
how does etag interwork with range requests? do you etag the master resource? |
| 20:24 |
|
whartung |
I ask that since mnay folks just hash to get the etag. |
| 20:24 |
|
whartung |
bah…brb |
| 20:28 |
|
trygvis |
etags should work fine when doing a GET, but you always POST the entire resource |
| 20:35 |
|
whartung |
yea that's why I'm insisting on it, because we do post the entire resource |
| 20:36 |
|
whartung |
the resoruces aren't fast movng, but big enough where the possibility of stomping on something is not zero. |
| 21:15 |
|
|
Coldblackice_ joined #rest |
| 21:15 |
|
|
metasansana joined #rest |
| 21:31 |
|
|
Coldblackice joined #rest |
| 22:21 |
|
|
fuzzyhorns joined #rest |
| 22:58 |
|
|
fuzzyhorns joined #rest |
| 23:52 |
|
|
quimrstorres joined #rest |
