| Time |
S |
Nick |
Message |
| 01:06 |
|
|
huckleberry78 joined #rest |
| 01:09 |
|
|
wsiqueir joined #rest |
| 01:21 |
|
|
baweaver joined #rest |
| 03:06 |
|
|
huckleberry78 joined #rest |
| 03:46 |
|
|
fuzzyhorns joined #rest |
| 04:41 |
|
|
fuzzyhorns joined #rest |
| 05:07 |
|
|
huckleberry78 joined #rest |
| 07:09 |
|
|
huckleberry78 joined #rest |
| 07:56 |
|
|
baweaver joined #rest |
| 08:08 |
|
|
talios joined #rest |
| 08:08 |
|
|
Blackskyliner joined #rest |
| 09:09 |
|
|
huckleberry78 joined #rest |
| 10:17 |
|
|
_ollie joined #rest |
| 10:21 |
|
|
quimrstorres joined #rest |
| 11:10 |
|
|
huckleberry78 joined #rest |
| 12:00 |
|
|
_ollie1 joined #rest |
| 13:11 |
|
|
huckleberry78 joined #rest |
| 13:44 |
|
|
_ollie joined #rest |
| 13:45 |
|
|
_ollie1 joined #rest |
| 13:52 |
|
|
_ollie joined #rest |
| 13:58 |
|
|
isundil joined #rest |
| 14:17 |
|
|
_ollie joined #rest |
| 14:18 |
|
|
_ollie1 joined #rest |
| 14:21 |
|
|
_ollie joined #rest |
| 14:23 |
|
|
_ollie2 joined #rest |
| 14:24 |
|
|
_ollie1 joined #rest |
| 14:31 |
|
|
_ollie joined #rest |
| 14:54 |
|
|
linux_dr joined #rest |
| 14:54 |
|
linux_dr |
Is this the right channel to discuss HAL? |
| 15:12 |
|
|
huckleberry78 joined #rest |
| 15:27 |
|
|
linux_dr joined #rest |
| 15:36 |
|
|
dkm joined #rest |
| 16:04 |
|
|
fuzzyhorns joined #rest |
| 16:30 |
|
|
_longines joined #rest |
| 16:34 |
|
pdurbin |
yep |
| 16:49 |
|
|
ozette joined #rest |
| 16:56 |
|
|
dkm joined #rest |
| 17:13 |
|
|
huckleberry78 joined #rest |
| 17:37 |
|
|
baweaver joined #rest |
| 18:23 |
|
|
rmwdeveloper joined #rest |
| 18:53 |
|
|
wsiqueir joined #rest |
| 19:14 |
|
|
huckleberry78 joined #rest |
| 20:05 |
|
|
FreezingDroid joined #rest |
| 20:44 |
|
|
dutmut joined #rest |
| 20:49 |
|
dutmut |
Hi. anybody here? |
| 20:50 |
|
trygvis |
just ask |
| 20:52 |
|
dutmut |
I'm trying to access "title" in a GET request but not sure how to get it from "body" http://hastebin.com/asibegexiw.vhdl |
| 20:52 |
|
dutmut |
hm, does anybody have an idea? |
| 20:53 |
|
dutmut |
also tried: body.items[0].title |
| 20:54 |
|
trygvis |
try #nodejs |
| 20:55 |
|
dutmut |
o okay, thanks! |
| 21:14 |
|
|
huckleberry78 joined #rest |
| 21:18 |
|
|
fuzzyhorns joined #rest |
| 21:34 |
|
|
quimrstorres joined #rest |
| 21:47 |
|
|
linux_dr joined #rest |
| 21:48 |
|
linux_dr |
Is anyone awake in here? |
| 21:48 |
|
trygvis |
no |
| 21:48 |
|
linux_dr |
Lol |
| 21:52 |
|
linux_dr |
I've heard more than my share of people wrestling with the idea of sessions with RESTful APIs. The strategy that I had adopted was to create a session resource, and do any operations requiring the session's permissions within the sessions' namespace... But that always struck me as disjoint from any shared resource URIs being modified.... |
| 21:55 |
|
linux_dr |
I just discovered the CONNECT HTTP method. Would it be reasonable to create a session resource via POST, then used CONNECT on the resource URI to perform POST/PUT/PATCH/DELETE on the resource URI... (proxying the permissions rather than the connection so to speak)? |
| 21:56 |
|
linux_dr |
Have you seen any RESTful permissioning mechanisms that you liked better? |
| 21:56 |
|
trygvis |
no |
| 21:56 |
|
trygvis |
can you even CONNECT to a particular resource? |
| 21:56 |
|
linux_dr |
Perhaps not.... |
| 21:57 |
|
trygvis |
anyway, CONNECT is a very strange part of http, not something you should use for RESTful stuff |
| 21:57 |
|
linux_dr |
Perhaps a Refered-by: with the session URI would be more appropriate? |
| 21:58 |
|
linux_dr |
I'm certainly open to a session-less solution, bit I haven't seen one that I've liked. |
| 21:59 |
|
linux_dr |
The idea of sending username & password with every request seems foolhardy. :-( |
| 22:01 |
|
linux_dr |
How would you recommend performing operations requiring permissions? |
| 22:01 |
|
trygvis |
sending the entire state with every request is the only way to become stateless, and that includes the username/password |
| 22:03 |
|
linux_dr |
But if you are implementing a database interface, already, for instance, the data ALREADY has state, if it can be modified. |
| 22:03 |
|
trygvis |
"all" APIs require that you send your token on every request, but some exchange the username/password with a token before they start |
| 22:03 |
|
linux_dr |
The question boils down to what is state? |
| 22:04 |
|
trygvis |
the resource is the state. the user fetches the entire resource and sends the entire resource back |
| 22:04 |
|
linux_dr |
trygvis: The session URI that I was referring to is exactly that: a token |
| 22:05 |
|
trygvis |
yes, that is an alternative way to do it. but then you're mainly reinventing stuff that is already there if you use it for authentication |
| 22:06 |
|
trygvis |
it is useful if your application requires you to go through a set of steps before doing some sort of "commit" or "publish" |
| 22:06 |
|
linux_dr |
My concern is not wanting the API consumer to retain the username and password. |
| 22:07 |
|
linux_dr |
Once the client sends the password, it should be discarded. |
| 22:07 |
|
trygvis |
because of it actually being a username and password and not a token? |
| 22:08 |
|
linux_dr |
Sessions are intended to be disposable. Passwords are intended to have relative durability. |
| 22:08 |
|
trygvis |
there is no such thing as a session :) |
| 22:09 |
|
trygvis |
anyway, I don't really understand what you see as a problem |
| 22:10 |
|
trygvis |
can't you get your clients to exchange their username/password for an ephemeral token you can use against your services? then only the authentication service will see the actual username/password |
| 22:10 |
|
linux_dr |
It's computer science... We model systems with abstractions that we create at will... We can create a session by merely defining it. |
| 22:11 |
|
trygvis |
sure, but then you're not following the ideas of REST |
| 22:13 |
|
pdurbin |
no cookies in REST |
| 22:13 |
|
linux_dr |
The real question is what does "stateless" mean. If we're being purely stateless, we can't store anything, so POST, PUT, PATCH, and DELETE are meaningless.... |
| 22:13 |
|
trygvis |
defining sessions with a Set-Cookie/Cookie header is a popular non-RESTful choice |
| 22:13 |
|
linux_dr |
pdurbin: nobody mentioned cookies |
| 22:13 |
|
trygvis |
you're misunderstanding stateless |
| 22:14 |
|
trygvis |
the resource can have state, but the interaction between the client and server is stateless |
| 22:14 |
|
linux_dr |
trygvis: I'm pointing out that we haven't agreed on a common definition yet. |
| 22:15 |
|
linux_dr |
trygvis: exactly... And I'm defining a session as a resource, with a URI |
| 22:16 |
|
trygvis |
this is #rest, the definition of stateless is given |
| 22:17 |
|
linux_dr |
I've read way too many articles on REST, and everybody seems QUITE confused on the meaning of stateless. |
| 22:17 |
|
trygvis |
true that |
| 22:19 |
|
linux_dr |
I have come up with my own ideas about how it is defined, and (based on what you have already said) I think they are fairly well aligned with yours, but I have yet to see a consistent definition. :-( |
| 22:19 |
|
|
pdurbin joined #rest |
| 22:20 |
|
linux_dr |
For starters, can we ignore the standard LAMP definition of sessions (involving cookies and whatnot) |
| 22:20 |
|
linux_dr |
? |
| 22:20 |
|
trygvis |
sure |
| 22:22 |
|
linux_dr |
If I POST to https://mysite.me/api/sessions with my username and password, and get a URI back of https://mysite.me/api/sessions/123456 does that violate REST? |
| 22:25 |
|
trygvis |
yes, if your intention is to hack around using the standard http headers/mechanisms |
| 22:25 |
|
linux_dr |
How do you mean? |
| 22:25 |
|
pdurbin |
how dare anyone violate rest |
| 22:25 |
|
fumanchu |
linux_dr: better call it api/foo/123456 to avoid preconceptions ;) |
| 22:26 |
|
linux_dr |
pdurbin: I have a 2 year old... I can never REST... lol |
| 22:26 |
|
pdurbin |
:) |
| 22:26 |
|
linux_dr |
fumanchu: sure... But we disc |
| 22:27 |
|
fumanchu |
what do you GET from such a URI? |
| 22:27 |
|
linux_dr |
Discounted the standard definition of "session" already |
| 22:28 |
|
linux_dr |
I get a private (because it was over https) resource that asserts my identity (and whatever permissions go with it). |
| 22:30 |
|
linux_dr |
I think I'd want that response to also contain a randomly generated value (to act like a password) to prevent someone from guessing a session URI |
| 22:31 |
|
linux_dr |
trygvis: so what kind of HTTP header hacking did you imagine I might do? |
| 22:31 |
|
trygvis |
hm? |
| 22:33 |
|
linux_dr |
You claimed my creation of a "session" resource would violate REST if I intended to "hack around using the standard http/mechanism" |
| 22:34 |
|
trygvis |
I meant you should use the standard 401/403 responses and the www-authenticate header instead of hacking around what is already there and inventing your own mechanism |
| 22:36 |
|
fumanchu |
linux_dr: what does that 123456 resoure do for you? or how do you use it? |
| 22:39 |
|
linux_dr |
trygvis: yes, 401/403 would be exactly what I'd use |
| 22:39 |
|
|
quimrstorres joined #rest |
| 22:42 |
|
linux_dr |
fumanchu: I could reference the session, (with confirmation hash) when I attempt to retrieve or modify another resource |
| 22:43 |
|
fumanchu |
reference how? in a cookie? |
| 22:44 |
|
fumanchu |
or in the request body? in the url? |
| 22:45 |
|
fumanchu |
in the request body is problematic for GET. in the URL leads to an explosion of URL's (N resources x M users), but then "Vary: Cookie" isn't much better |
| 22:47 |
|
linux_dr |
fumanchu: that was, very much the question. I started this conversation wondering if a CONNECT verb might be fitting... but I was grasping at straws... I certainly wouldn't use a cookie... I could certainly use the session URI as the resource prefix, which I've done before... Or perhaps in the request body, or perhaps a Refered-by: but that's a stretch... Open to ideas. |
| 22:48 |
|
fumanchu |
what's wrong with the cookie approach? |
| 22:49 |
|
linux_dr |
fumanchu: well... It violates statelessness, if nothing else... No? |
| 22:51 |
|
fumanchu |
"statelessness" is there for one reason: scalability. you want to host the info on a virtually unlimited number of machines, without tying one client to one server |
| 22:51 |
|
linux_dr |
Anyone? |
| 22:53 |
|
fumanchu |
so as long as any of your servers can look up the required info based on a cookie token, the connection is not "stateful" |
| 22:55 |
|
linux_dr |
Using cookies feels like the wrong solution... :-( i'm happy to be wrong, but i'm not yet convinced |
| 23:00 |
|
fumanchu |
it's easy to mix cause and effect here. sending a cookie, or a different header, or an extra querystring arg is not "stateful". sending *nothing* would be "stateful" because it means the server has to keep track of your session based on your IP or a persistent connection |
| 23:01 |
|
|
quimrstorres joined #rest |
| 23:01 |
|
fumanchu |
you typically have to analyze the constraints of the REST style by comparing them to architectures other than HTTP, not different ways to use HTTP |
| 23:02 |
|
fumanchu |
since the REST style guided the design of HTTP, not the other way around |
| 23:02 |
|
fumanchu |
SSH, for example, is "stateful" because each packet does not contain everything the server needs to know about your session |
| 23:02 |
|
fumanchu |
it got all that at the beginning of the conversation |
| 23:02 |
|
pdurbin |
linux_dr: maybe you can send an API token |
| 23:03 |
|
fumanchu |
HTTP/2 is not RESTful on this same point |
| 23:12 |
|
|
linux_dr joined #rest |
| 23:15 |
|
|
huckleberry78 joined #rest |
| 23:26 |
|
|
linux_dr joined #rest |
| 23:27 |
|
linux_dr |
Sorry... Back... iOS got grumpy... Lol |
| 23:34 |
|
pdurbin |
linux_dr: maybe you can send an API token |
| 23:35 |
|
fumanchu |
http://dilbert.com/strip/1995-06-24 |
| 23:36 |
|
dutmut |
Hey guys. I need some simple explanation on what to do when you've gotten the body from a GET request. What do I do to get useful information from it? Make it a string? how do I get specific things from it etc. Could anyone here point me to a place to read about that? Because all the places I read about get requests, they end before this point... Thanks! |
| 23:37 |
|
fumanchu |
that depends entirely on the Content-Type of the response and your client-side programming environment. probably a question for an IRC channel dedicated to the latter. |
| 23:39 |
|
dutmut |
hmm well I get a "body" as an object but if I make that a string and print it I can see the response in JSON.. uhm |
| 23:40 |
|
fumanchu |
in Javascript? Python? Java? .Net? Perl? R? what? |
| 23:40 |
|
dutmut |
this is an example of the response (body) http://prntscr.com/7un695 in javascript, nodejs |
| 23:41 |
|
dutmut |
I want to get the content of "title" (the very last line) |
| 23:41 |
|
dutmut |
but.. I don't even know what to do with the "body" object |
| 23:41 |
|
fumanchu |
that'd be a question for a #node.js channel |
| 23:42 |
|
fumanchu |
http://webchat.freenode.net/?channels=node.js |
| 23:42 |
|
dutmut |
hmm yeah, but I'd just like to know more about REST and get requests in general though |
| 23:42 |
|
dutmut |
Like, I heard about stringify |
| 23:42 |
|
dutmut |
but I don't really understand when you would use that etc |
| 23:43 |
|
|
linux_dr joined #rest |
| 23:43 |
|
dutmut |
I feel like I need more background knowledge about REST before attempting this maybe |
| 23:43 |
|
fumanchu |
it doesn't sound like it. you should ask in #nodejs instead. |
| 23:43 |
|
fumanchu |
sorry, #node.js |
| 23:44 |
|
dutmut |
well thanks then! |
| 23:53 |
|
fumanchu |
he didn't ask there either |
