| Time |
S |
Nick |
Message |
| 00:50 |
|
|
fuzzyhor_ joined #rest |
| 02:06 |
|
|
wsiqueir joined #rest |
| 02:48 |
|
|
ralphschindler joined #rest |
| 02:49 |
|
|
baweaver joined #rest |
| 03:45 |
|
|
fuzzyhor_ joined #rest |
| 03:52 |
|
|
talios joined #rest |
| 07:13 |
|
|
rosstuck joined #rest |
| 07:45 |
|
|
interop_madness joined #rest |
| 07:57 |
|
|
graste joined #rest |
| 08:44 |
|
|
quimrstorres joined #rest |
| 08:53 |
|
|
linux_dr joined #rest |
| 09:13 |
|
|
quimrstorres joined #rest |
| 09:36 |
|
|
linux_dr joined #rest |
| 10:20 |
|
|
linux_dr joined #rest |
| 12:17 |
|
|
quimrstorres joined #rest |
| 12:23 |
|
|
prologic joined #rest |
| 12:52 |
|
|
Guest77585 joined #rest |
| 12:54 |
|
|
prologic joined #rest |
| 13:41 |
|
|
linux_dr joined #rest |
| 14:14 |
|
|
linux_dr joined #rest |
| 14:32 |
|
|
linux_dr joined #rest |
| 14:40 |
|
|
quimrstorres joined #rest |
| 14:50 |
|
|
linux_dr joined #rest |
| 14:50 |
|
|
wsiqueir joined #rest |
| 15:10 |
|
|
linux_dr joined #rest |
| 15:21 |
|
|
sfisque joined #rest |
| 15:21 |
|
|
linux_dr joined #rest |
| 15:30 |
|
|
eschmidbauer joined #rest |
| 15:32 |
|
|
eschmidbauer left #rest |
| 15:32 |
|
|
quimrstorres joined #rest |
| 17:03 |
|
|
fuzzyhorns joined #rest |
| 18:20 |
|
|
eschmidbauer joined #rest |
| 18:33 |
|
|
quimrstorres joined #rest |
| 18:55 |
|
|
eschmidbauer left #rest |
| 19:38 |
|
|
foist joined #rest |
| 19:41 |
|
foist |
Is it possible to cache a /me endpoint? For instance, /me/following? |
| 19:41 |
|
trygvis |
everything is possible to cache, but if it makes sense, probably not |
| 19:45 |
|
foist |
trygvis: could you elaborate please? |
| 19:46 |
|
trygvis |
everything is possible to cache, but that URL doesn't look very useful to cache |
| 19:46 |
|
trygvis |
I must have been drunk when I wrote that line.. |
| 19:48 |
|
foist |
trygvis: is there something WRT caching that cannot be done with `/me/following` which can be done with `/myusername/following`? |
| 19:50 |
|
trygvis |
the point is that if you have /123/following it can be cached by intermediates, but /me/following cannot as everyone has to get their own version |
| 19:54 |
|
|
anarcat joined #rest |
| 19:54 |
|
|
anarcat left #rest |
| 19:55 |
|
foist |
trygvis: excuse my ignorance; what are intermediates? |
| 19:56 |
|
trygvis |
any server between the client and origin server |
| 19:56 |
|
trygvis |
a cache is one example |
| 19:57 |
|
foist |
trygvis: why would I have any proxy (intermediate) server between my clients and my server? |
| 19:59 |
|
trygvis |
perhaps because you or someone else want to cache something. or provide security |
| 19:59 |
|
foist |
trygvis: So in your example, you meant that the cache itself would be an intermediate? |
| 20:00 |
|
trygvis |
well, yes |
| 20:00 |
|
trygvis |
it could also be a part of your client code, some clients have built-in caches and/or transformation layers |
| 20:00 |
|
|
sfisque joined #rest |
| 20:01 |
|
foist |
Couldn’t you still get equal results (in terms of improving performance by reducing load through caching) by doing the caching at the DB level? |
| 20:01 |
|
trygvis |
that might be |
| 20:02 |
|
trygvis |
but you can always slap a cache in front of your http server |
| 20:03 |
|
foist |
trygvis: I don’t know what you mean by that last message. |
| 20:06 |
|
trygvis |
you can use an existing product like squid or varnish to add a cache as an intermediate in between your client and your server |
| 20:29 |
|
whartung |
foist YOU may well not have an intermediary, but a company almost certainly has something between the workstation and your server |
| 20:29 |
|
whartung |
these are intermediaries you have no control over |
| 20:30 |
|
foist |
whartung: I don’t have a public API. |
| 20:30 |
|
whartung |
then you don't have to worry about it then |
| 20:31 |
|
whartung |
but as trygvis was commenting, "/me/following" sounds very specify to the current user (which implies it's not stateless), whereas /123/following works fine as it's most likely a unique resource name |
| 20:32 |
|
foist |
trygvis: weren’t you saying it _is_ stateless a little while ago? Could have been someone else. |
| 20:33 |
|
whartung |
as long as I get the same value of /me/following as you or trygvis does, then it's cetainly stateless. |
| 20:33 |
|
whartung |
but just the name of the url suggests otherwise |
| 20:33 |
|
whartung |
the more static the reosurce, the more caching will help |
| 20:33 |
|
whartung |
you can also cache at the client level |
| 20:34 |
|
whartung |
that's the magic of the caching headers -- you announce to the consumers the caching semantics of your resources, and they can choose to act on them or not. |
| 20:41 |
|
|
baweaver joined #rest |
| 20:46 |
|
foist |
whartung: Spotify for instance has a `/me/following` resource. When you do a GET request on it, it will give you a list of the artists you’re following. Isn’t this a violation of REST? |
| 20:48 |
|
whartung |
not necessarily. The resource is rendered based on the request. The request is a combination of the name of the reosurce and the headers. For example, a request that return identical data formatted in xml vs JSON (based on the Accept header) is perfectly acceptable. So, in this case, you may have a request based on the Authorization header. (I don't know what exactly they do, just suggesting RESTful mechanisms under which they can be don |
| 20:48 |
|
whartung |
However. |
| 20:49 |
|
whartung |
That doesn't mean they're a particularly CACHEABLE request. |
| 20:49 |
|
whartung |
that depends on teh criteria the the caching system uses |
| 20:49 |
|
whartung |
some may well just cache on the name, and that's not enough in this case to distinguish the proper payload for a resource |
| 21:04 |
|
foist |
I think there’s too much I don’t know to make any sensible decision about this sorta stuff. |
| 21:05 |
|
whartung |
well you can always ask questions, we're just chock full of opinions, and some facts... |
| 21:23 |
|
|
sfisque joined #rest |
| 21:55 |
|
|
wsiqueir joined #rest |
| 21:55 |
|
|
fuzzyhorns joined #rest |
| 21:55 |
|
|
Coldblackice joined #rest |
| 22:31 |
|
|
fumanchu_ joined #rest |
| 22:46 |
|
|
fuzzyhorns joined #rest |
| 22:58 |
|
|
baweaver joined #rest |
| 23:17 |
|
|
pokEarl joined #rest |
