greptilian logo

IRC log for #rest, 2014-05-28

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:10 shrink0r joined #rest
02:29 fumanchu_ joined #rest
04:11 jzsprague joined #rest
05:51 talios joined #rest
06:33 rosstuck joined #rest
07:32 _ollie joined #rest
07:59 jzsprague joined #rest
08:03 interop_madness joined #rest
08:32 Left_Turn joined #rest
09:04 martinfilliau joined #rest
09:40 ssedano joined #rest
09:41 graste joined #rest
09:46 shrink0r joined #rest
11:16 graste joined #rest
11:39 shrink0r joined #rest
12:10 pdurbin interesting write up about PATCH: Go, REST APIs, and Pointers - https://willnorris.com/2014/05/go-rest-apis-and-pointers
12:57 ssedano joined #rest
13:31 jzsprague joined #rest
13:36 charlex joined #rest
13:41 seantallen joined #rest
14:05 m0ltar joined #rest
14:23 fumanchu joined #rest
14:54 _ollie joined #rest
14:54 molten_tar joined #rest
14:57 m0ltar joined #rest
15:01 locks joined #rest
15:11 m0ltar joined #rest
15:23 Left_Turn joined #rest
15:33 nkoza joined #rest
15:40 molten_tar joined #rest
16:00 m0ltar joined #rest
16:13 danizord joined #rest
16:26 molten_tar joined #rest
16:28 m0ltar_ joined #rest
16:33 m0ltar joined #rest
16:37 molten_tar joined #rest
16:47 charlex joined #rest
16:57 charlex joined #rest
16:59 charlie_ joined #rest
17:18 charlex joined #rest
17:19 m0ltar joined #rest
17:22 m0ltar_ joined #rest
17:27 m0ltar joined #rest
17:47 molten_tar joined #rest
18:04 graste joined #rest
18:42 jzsprague joined #rest
18:52 jzsprague joined #rest
18:55 m0ltar joined #rest
18:58 molten_tar joined #rest
19:43 ldiamond joined #rest
19:48 ldiamond suppose there are users and items on the server. Users can 'like' items. /items/{id} would get an item, but how would a user like an item? /like/{item_id}, /user/{id}/like/{item_id}, /item/{id}/like?
19:49 ldiamond I'm leaning towards /like/{item_id} since the user is known through authentication already. That would be something like "I like item X".
20:01 whartung POST a user id to /like/{item_id}
20:04 ldiamond I was thinking about an empty POST to /like/{item_id} since the user_id is already in the cookie
20:04 whartung well, that's utterly wrong.
20:04 ldiamond why?
20:05 whartung you shouldn't be using cookies, especially not for this. This should be a first class operation.
20:05 ldiamond Well, the user MUST be authenticated.
20:05 whartung yea. so?
20:06 ldiamond once we get the request we already know the user id, whether from the cookie or the session id
20:06 whartung ok, well do whatever you want. You will anyway.
20:06 ldiamond I'm trying to understand your point.
20:07 whartung I'd love to explain it, but I don't have the time since I would have to explain core, fundamental axioms of REST. But it's clear to me you're NOT doing REST, so, it's really pretty moot at this point.
20:09 ldiamond I'm doing REST. But such user actions are authenticated. You'd suggest getting the user_id via post and validating user_id == authenticated_user_id?
20:09 whartung what makes you think you're doing REST?
20:11 ldiamond Cause I'm trying my best to structure the service using resources, to keep the same interface for all resource using correct http verbs, remaining stateless, making it cacheable, etc
20:12 whartung but you're not stateless. You're not doing first class operations. and the fact that your suggestion came quickly, tells me that these fundamentals are not ingrained in your design.
20:12 ldiamond The design isn't done yet.
20:13 seantallen joined #rest
20:14 ldiamond It is stateless as far as resources are concerned. The user authentication isn't but I don't see any easy way around that.
20:15 ldiamond define 'first class operations'
20:15 whartung why don't you see any way around authorization?
20:16 ldiamond a user needs to be authorized to modify the resource for a /like.
20:17 whartung so what's wrong with the authorization header?
20:18 ldiamond what's different between the authorization header and the authorization cookie as far as keeping the POST content empty?
20:18 whartung semantics
20:19 whartung What's the difference between POST and ACTION?
20:20 ldiamond So you'd send the user_id in the post data and simply ignore it on the server?
20:21 whartung No, I'd validate that the authencated user had the rights to create a LIKE for the User Id that's submitted, and then execute or reject it.
20:21 whartung now, an Admin can post a LIKE for someone, or a Test, or a bulk loader, or anything else you want.
20:26 ldiamond I guess if /like can be performed by another user I could use it but there's no use-case for that right now.
20:29 whartung RESt is about Resources and their manipulations. Resources are the First Class concept within REST. Side effects, and who not, are not. Adding a USER to a LIKE list is a simple concept, and the user should be a first class resource, not something implied. This is a World View that you should be using to see your entire architecture. This one instance should not be an exception just because the person is "logged in".
20:31 ldiamond Then why isn't a POST {item_id} to /user/{id}/like preferred.
20:32 whartung that works to
20:32 whartung too
20:32 whartung it depnds on whether you're maintain a list of users that like items or items a user likes
20:34 ldiamond both are maintained.
20:34 fumanchu it's typically both, but usually you want the user to have a fresh view of their likes more immediately than everyone a fresh view of how many likes an item has
20:34 whartung but that's an implementaiton detail
20:34 fumanchu so you want the POST action to invalidate /users/{id}/likes/
20:35 whartung welcome to the fun side of caching...
20:36 ldiamond well that's not going to be necessary since /users/{id}/likes/ won't exist
20:36 whartung then it's not an issue is it?
20:37 fumanchu "won't" is a very long time
20:37 fumanchu it will exist in some future iteration of the API. you'll see. ;)
20:37 ldiamond well, at that point I'll invalidate the cache :P
20:43 ldiamond Is there any good resource about naming "conventions"?
20:44 whartung I'm a big fan of english, but then, I don't really speak anything else.
20:45 ldiamond more precise than that, for example, I tend to prefer /users/ to list all users, /user/{id} to get a single user such that I could use /users/8 to get 8 users.
20:46 whartung ok
20:46 ldiamond Not sure if that's considered 'bad'.
20:47 whartung after the intiial resources, the names don't really matter a whole lot, since they're provided by the system.
20:47 ldiamond I guess the point is just consistency across the service.
20:48 whartung consistency is following the rels appropriately, and making the proper rels available.
20:52 whartung I can order anything from amazon.com without knowing anything but the "/" resource: "http://amazon.com/", and never see or care about a resource name again.
20:53 ldiamond not sure I understand your point.
20:54 fumanchu the only guide is that the HTTP path is defined to be hierarchical
20:54 ldiamond My comment was about "users" vs "user", are you talking about "/" vs no "/"?
20:54 whartung I'm saying that outside of some fundamental resources, resource names get increasingly less important. rels are important.
21:22 talios joined #rest
21:23 talios joined #rest
21:50 pdurbin whartung: are you talking about your own experience using Amazon's API? (I've never used it.) Sounds like it's pretty good about rels and etc.
21:51 whartung no, I'm talking about their website
21:54 pdurbin oh
21:55 whartung and I'm always loathe to use a web site as a REST example (as they're generally terrible at it, and the browser is a terrible REST client), but for this case, it's representative of HATEOAS
21:56 pdurbin so what's the best REST example then?
21:58 whartung I can't rally cite any in the wild
21:58 m0ltar joined #rest
21:59 pdurbin bummer
22:03 whartung browser apps capture the essence of rest at a high level, and help exemplify things, notably HATEOAS. But many are not particularly RESTy in their own right. I'm sure Amazons isn't.
22:07 pdurbin I guess we'll get there. As an industry. Some day.
22:07 whartung some day
22:07 whartung but consider
22:07 whartung you go to amazon.com to buy a pack of gum
22:08 whartung you hit the home page, and you're offered a bunch of labeled links
22:08 whartung one is a simpe form call "search"
22:08 whartung you type in "gum"
22:08 whartung and you're presented with a selection of "things that somehow amazon things relates to gum"
22:08 whartung you then follow links to page through this data, or whatever
22:09 whartung or eventually you select one
22:09 whartung you follow a link to stuff it in a shopping cart
22:09 whartung then you follow a link to check out, etc.
22:09 Left_Turn joined #rest
22:09 pdurbin sure
22:09 whartung at no time, really, save for "amazon.com" do you really have any inkling or input in to what resource names are or the URLs you used.
22:10 whartung you just followed rels manifested by links (mostly)
22:10 whartung THAT is "HATEOAS"
22:10 whartung following links == HATEOAS
22:11 whartung so, you can see why when folks get all caught up in "what the urls look like" or "what should they be called", it's not really germane in practice.
22:11 whartung as humans, we like to project order to such things, sure.
22:12 whartung No one wants to just use random GUIDs for links, and pull a new one off the heap every time you want a new "name"
22:12 whartung but having tedious meetings over them…mostly pointless.
22:12 pdurbin yeah, no GUIDs. we like beautiful things
22:13 whartung "So, what is a remote client supposed to hit the index page for every request?"
22:13 whartung Well, actually, "yes"
22:13 whartung beacuse the urls are not in the client control
22:13 whartung they can "change at any time"
22:14 whartung "but that's inefficient!"
22:14 whartung yes it is, so cache it
22:14 whartung what's the difference between a list of URLs pulled down from a service and a set hard coded in to the app? One can change as necessary, the other can't. But, in the end, the app doesn't care. Internally it has a map of rels -> URLs.
22:15 whartung who cares how this map is developed?
22:15 whartung rels matter, URLs don't.
22:15 whartung do you know the memory pointer of your function calls when compiled?
22:15 whartung Nope.
22:15 whartung I don't
22:15 whartung most don't
22:15 whartung I know the names of the functions I call, though.
22:16 whartung function nam -> code address, rel name -> URL.
22:16 whartung effectively the same thing
22:18 pdurbin yeah, in AtomPub you hit the "service document" first. it tells you where to go from there
22:47 molten_tar joined #rest
22:50 talios Morning
22:51 m0ltar joined #rest
22:56 pdurbin talios: mornin'
23:03 * pdurbin looks at RFC 5023 - The Atom Publishing Protocol - http://tools.ietf.org/html/rfc5023
23:03 pdurbin I wonder how standard rels like "edit" and "edit-media" are.
23:05 pdurbin looks like there's also rel=first ... previous, next, last
23:05 pdurbin rel=alternate
23:07 talios http://www.iana.org/assignments/link-relations/link-relations.xhtml has the full list of the IANA registered ones
23:07 talios including edit, next, previous, start
23:08 pdurbin interesting... "payment" ... thanks, talios
23:09 talios that page also links to the various protocol/specs that registered them
23:09 pdurbin "Standardized link relations are one of the foundations of HATEOAS" -- http://en.wikipedia.org/wiki/Link_relation
23:11 jzsprague joined #rest
23:12 pdurbin so what are the standardized link relations for HATEOAS?
23:12 molten_tar joined #rest
23:13 locks the ones talios linked
23:13 locks :P
23:13 pdurbin oh
23:16 talios 'lo locks
23:16 * pdurbin looks at http://stackoverflow.com/questions/13377350/hateoas-rel-any-standards-yet
23:17 * talios must get off his bum and release a new version of HalBuilder
23:17 locks heya
23:17 locks and I of halibut lol
23:18 locks I don't get it
23:18 locks HAL is a media type
23:20 locks is CURIE links
23:20 locks to make custom rels more palatable
23:33 talios palatable for humans maybe, but for machines I don't see it should really matter. and kinda makes things more difficult IMHO, ish.

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

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