| 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. |
