greptilian logo

IRC log for #rest, 2015-08-11

https://trygvis.io/rest-wiki/

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

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

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

https://trygvis.io/rest-wiki/