| Time |
S |
Nick |
Message |
| 00:04 |
|
|
fuzzyhorns joined #rest |
| 01:01 |
|
|
rmwdeveloper joined #rest |
| 02:13 |
|
|
huckleberry78 joined #rest |
| 03:33 |
|
|
wsiqueir joined #rest |
| 03:35 |
|
|
fuzzyhorns joined #rest |
| 04:12 |
|
|
fumanchu joined #rest |
| 04:14 |
|
|
huckleberry78 joined #rest |
| 05:24 |
|
|
philbot joined #rest |
| 05:24 |
|
|
Topic for #rest is now #rest REpresentational State Transfer | logs: http://irclog.greptilian.com/rest/today | http://tech.groups.yahoo.com/group/rest-discuss | http://code.google.com/p/implementing-rest/ | http://en.wikipedia.org/wiki/Representational_State_Transfer |
| 05:27 |
|
|
ekroon joined #rest |
| 05:30 |
|
|
igitoor_ joined #rest |
| 05:33 |
|
|
baweaver joined #rest |
| 05:35 |
|
|
bigbluehat joined #rest |
| 06:15 |
|
|
huckleberry78 joined #rest |
| 06:24 |
|
|
daxim_ joined #rest |
| 07:03 |
|
|
_ollie joined #rest |
| 07:21 |
|
|
interop_madness joined #rest |
| 08:26 |
|
|
fumanchu joined #rest |
| 08:54 |
|
|
graste joined #rest |
| 08:55 |
|
|
huckleberry78 joined #rest |
| 08:57 |
|
|
quimrstorres joined #rest |
| 09:02 |
|
|
quimrstorres joined #rest |
| 09:59 |
|
|
_ollie joined #rest |
| 11:01 |
|
|
quimrstorres joined #rest |
| 12:03 |
|
|
Blackskyliner joined #rest |
| 12:07 |
|
Blackskyliner |
Hey there, quick question. Is there any topic which chould be handled in a BA Thesis titled "Demonstrative implementation of an RESTful Service at the example of an chess application" - I thought about something like: how to keep the state out of, mostly stateful apps and how to transofrm stateful api's to stateless ones, or better to keep the rules defined by fielding. - I just need some academical thing to research in my thesis |
| 12:07 |
|
Blackskyliner |
and I really struggle to find something not already widely elaborated... |
| 12:24 |
|
pdurbin |
Blackskyliner: well, HTTP is already stateless |
| 12:29 |
|
Blackskyliner |
Yea but we "patched" the state through Session ID's and State which resides on the server/connector. Whilist the REST philosophy based on fieldings thesis is, that no state is saved on the server and all requests should be self-containing without the server having to remember stuff. |
| 12:33 |
|
pdurbin |
that makes it sound like your server can't have a database containing state if you want to refer to your API as RESTful |
| 12:37 |
|
Blackskyliner |
pdurbin, thats in my eyes exactyl what I would like my thesis to refer about, but I don't know if its academical enough... Its about how to conform to beeing REST (stateless) but also having some kind of identification or "hidden" state behind the API. In the end its an IN->OUT model. I supply ALL needed information so an service on the Endpoint can supply the answer. To be scalable I will not assume that the connector knows any |
| 12:37 |
|
Blackskyliner |
state which could be loaded. But this does not imply I can't access a database to retrieve information. If its my duty to do so I do it. But to solve the request sent I should only use the information/data I got throiugh the request. |
| 12:39 |
|
Blackskyliner |
This is how I understood the thesis of fielding. Never asume any state on the server, be atomic on your handling of requests, and so on. |
| 12:40 |
|
Blackskyliner |
Without those assumptions, btw, caching or scaling the API would be PITA. |
| 12:41 |
|
Blackskyliner |
at least as far as I got all this whole concept/architecture |
| 12:45 |
|
pdurbin |
it says "The client-stateless-server style derives from client-server with the additional constraint that no session state is allowed on the server component. Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server." |
| 12:45 |
|
pdurbin |
https://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm |
| 12:45 |
|
Blackskyliner |
Exactly what I refer to. |
| 12:48 |
|
Blackskyliner |
Everything else, where I owuld need a state (like authenticatio, authorization) should/can be handled through a middleware. Thus leaving the API completely stateless for it self. Or am I wrong? |
| 12:51 |
|
Blackskyliner |
Because the second the server knows who I am I can imply an state to the server side. As with Session ID's which are stored on the server side to identify returning users. Leading to an internal processing of an attribute, fetching and comparing. Then handling my request with the provided data if I am authorized. This loading of session data would be a server side state.... Now I don't know if its just an philosophical aspect or |
| 12:51 |
|
Blackskyliner |
overthinking of the concept from my side.... |
| 12:51 |
|
Blackskyliner |
In the end I have to have an API with no state. (If I want to call it an true REST API though) |
| 12:52 |
|
Blackskyliner |
The Limitations I apply to the system would be made by intermediary services which handle those (maybe stateful) interactions/descisions. |
| 12:53 |
|
pdurbin |
Blackskyliner: if you hang around people who know REST much better than I do will probably be interested in chatting. Once they're awake. :) |
| 12:54 |
|
Blackskyliner |
So you also don't really know? Phew, good I'm not alone :) |
| 12:55 |
|
pdurbin |
I hang out here hoping the REST stuff rubs off on me. |
| 13:29 |
|
|
quimrstorres joined #rest |
| 13:32 |
|
|
quimrstorres joined #rest |
| 13:37 |
|
|
pith joined #rest |
| 13:41 |
|
pith |
hi, does anyone use the JSON-HOME ietf draft ? (tools.ietf.org/html/draft-nottingham-json-home-03) |
| 13:42 |
|
asdf` |
Blackskyliner, hmm, any examples of the 'state' you'd like to avoid? |
| 13:45 |
|
|
huckleberry78 joined #rest |
| 13:57 |
|
Blackskyliner |
asdf: Well in the example of the chess game I have as target of my thesis, I think a running game, with either 1 player and 1 ki or 2 player playing against each other. represented through the REST API, now I know how to model it the ways I don't have to assume a state for the easier tasks, but what about the "who is able to participate in a game"? Should I use tokens, which each person gets when attending a game, which then gets |
| 13:57 |
|
Blackskyliner |
used as identifier within the request? But is this than nthing more than an implied state on the server? |
| 13:58 |
|
Blackskyliner |
I could translate this problem onto a middleware, so I get an 403 if the person does not have the right to play the game. |
| 13:58 |
|
Blackskyliner |
But I don't know if I overthink the whole stateless definition in there. |
| 13:59 |
|
Blackskyliner |
Also I'd like to get something I could write about which is somehow academically relevant to my topic I got... |
| 14:00 |
|
Blackskyliner |
So do you see anythin I could center my thesis about, e.g. comparing about state and how to transform them so they get stateless or avoided in the end? |
| 14:02 |
|
|
metasansana joined #rest |
| 14:20 |
|
asdf` |
Blackskyliner, of course, sending a session id, or some token, or the login name and a password, all assume some state on the server |
| 14:21 |
|
asdf` |
(nb. with REST, the protocol needs to be stateless, not the application; the point of having some state is the point of having an application ;) ) |
| 14:25 |
|
fumanchu |
right. it's not "I can't remember how many hammers I have left to sell" but "I'm not going to bother to remember what you looked at yesterday just so I can have it at the counter today" |
| 14:26 |
|
fumanchu |
I think I just proved that if you have a marketing team, you don't want REST. |
| 14:26 |
|
fumanchu |
there's your thesis |
| 14:30 |
|
fumanchu |
what we *really* need a thesis on is an architectural analysis of HTTP/2. what are the (especially non-functional) requirements that are driving that architecture? |
| 14:35 |
|
Blackskyliner |
fumanchu: this seems to be much more than a BA thesis could hold, size wise. - Aslo I am somewho restrained to some REST topic because of the topic I got from my prof. |
| 14:35 |
|
pith |
fumanchu: what king of architectural analysis are you talking about ? Because if I understood well, HTTP/2 just changed the transport not the architecture |
| 14:35 |
|
fumanchu |
ha. "just" |
| 14:35 |
|
Blackskyliner |
So if I use like a Identification Header or an Identitication Token for like POST actions I do not break the stateless aspect of REST? |
| 14:36 |
|
pith |
well it's huge change "just is not really appriopriate you are right |
| 14:37 |
|
pith |
but what does it change in our architecture ? |
| 14:38 |
|
fumanchu |
pith: the largest area in my mind: HTTP/1 was designed using the REST style which includes a reliance on caching for efficiency (which promotes larger messages). HTTP/2 promotes small messages and seems to want to rely on "just in time" delivery for efficiency. |
| 14:39 |
|
fumanchu |
it doesn't have a defined style so it's a bit more vague |
| 14:39 |
|
pith |
ok I see, thanks for this explanation |
| 14:40 |
|
pith |
so the verb PATCH will be more used with HTTP/2 than it was before I guess |
| 14:46 |
|
fumanchu |
I think we'll see lots of sites that want a ton of tiny messages embrace HTTP/2 because it's lower overhead than HTTP/1 for that. But then they'll hit real load and realize a ton of tiny messages just doesn't scale on TCP no matter how you frame it. |
| 14:47 |
|
fumanchu |
well, 2% of those sites will hit real load |
| 14:47 |
|
Blackskyliner |
I would guess that developers may switch to websockets for a really frequent transmission of tiny messages, but I guess only time will tell. |
| 14:50 |
|
fumanchu |
Blacksky_afk: come intern with us and you can write your thesis on how media-types can be designed to help constrain the architectural style (including REST) |
| 14:53 |
|
pith |
Oh I would love to work on this ! But I'm not a student anymore :( |
| 14:56 |
|
pith |
Do you already have some materials (article or thesis) about it ? |
| 14:58 |
|
fumanchu |
just the spec for Shoji, which includes architectural reasons interspersed why it is the way it is: https://bitbucket.org/fumanchu/shoji/src/tip/spec.txt?at=default |
| 15:09 |
|
|
wsiqueir joined #rest |
| 15:30 |
|
|
foist joined #rest |
| 15:58 |
|
|
_ollie joined #rest |
| 15:59 |
|
|
quimrstorres joined #rest |
| 16:24 |
|
|
quimrstorres joined #rest |
| 16:28 |
|
|
_ollie1 joined #rest |
| 16:29 |
|
|
quimrstorres joined #rest |
| 16:40 |
|
|
Blackskyliner joined #rest |
| 17:27 |
|
|
quimrstorres joined #rest |
| 17:58 |
|
|
quimrstorres joined #rest |
| 18:48 |
|
|
quimrstorres joined #rest |
| 19:10 |
|
|
_ollie joined #rest |
| 19:12 |
|
Blackskyliner |
How do I have to interpret: A state mechanism that involves preferences can be more efficiently implemented using judicious use of context-setting URI rather than cookies, where judicious means one URI per state rather than an unbounded number of URI due to the embedding of a user-id. (fielding 6.3.4.2) So I may not add something like the user_id to an url? What about deep linked collections? When I would be tempted to make an URI |
| 19:12 |
|
Blackskyliner |
like /users/1/invoices/2 - Does it refer to not deeply embed the linkage/connection between resources which an URI may point to? si instead of the earlier example I should use /invoces/2 and /users/1 but not interconnect them via the URI? (I know this section is about cookies in general, but it seems more general formulated, thats why I asking) |
| 19:18 |
|
impl |
Blackskyliner: let's say you have a multipage form or something, if you have /user1/res1 -> /user1/res2 -> /user1/res3, and that form is really contextually only available to the current user, you may as well pick the user up from the Authorization header and call it /res1 -> /res2 -> /res3 |
| 19:20 |
|
impl |
Blackskyliner: so it's not really as applicable to your example... that said, if it were me, i'd probably make invoices available both under /invoices as a general endpoint and /users/xyz/invoices as the list of invoices specifically for that user (could even be a redirect to /invoices?user-filter=xyz or something) |
| 19:22 |
|
Blackskyliner |
But how does this comply with what I just c&p from fieldings diseration? |
| 19:23 |
|
Blackskyliner |
Or to ask another way: What does he mean with an unbound number of URI due to embedding a user_id? |
| 19:24 |
|
fumanchu |
he means: don't end up with /foo?user_id=3, /bar?user_id=3, ... for every endpoint in your API |
| 19:25 |
|
impl |
(because your API is authenticated already) |
| 19:25 |
|
fumanchu |
because /foo?user_id=3 is a different URI than /foo?user_id=4 |
| 19:25 |
|
Blackskyliner |
Ah so its just about the Authorisation aspect. |
| 19:25 |
|
impl |
Blackskyliner: it's more like that you can use context from the headers to decide how to send output. |
| 19:26 |
|
Blackskyliner |
impl, thanks for the clarification of that particular line. |
| 19:37 |
|
|
rmwdeveloper joined #rest |
| 20:24 |
|
whartung |
no, it's not just a authorisation issue Blackskyliner |
| 20:25 |
|
whartung |
it's basically the stateless concern that they're talking about |
| 20:30 |
|
|
quimrstorres joined #rest |
| 20:31 |
|
Blackskyliner |
So whats not stateless about attaching the user_id on to the URI? It will in this case solve the request will all the provided information given by the request. |
| 20:32 |
|
whartung |
Well, simply, reources are identified by URLs, and adding the user_id to the resrouce renames the resource. |
| 20:33 |
|
whartung |
Arguably, they are "different resources". /potato?uesr_id=1 is different from /potato?user_id=2 |
| 20:34 |
|
whartung |
but that only makes sense if the user id is there in fact to affect the outcome of the resource |
| 20:34 |
|
whartung |
i.e. can anyone get /potato?user_id=1? or just a user who'd user ID is 1? |
| 20:34 |
|
whartung |
Because Authn/Authz is a "cross cutting" concern. It potentially affects "everything" |
| 20:35 |
|
whartung |
So, we have an Authentication header to manage that aspect of the transaction |
| 20:36 |
|
whartung |
We have area specifically to handle these concepts. Consider: GET /thing.xml Accept: application/json … |
| 20:36 |
|
whartung |
what kind of payload will you get back? |
| 20:36 |
|
whartung |
vs GET /thing Accept: applpication/xml |
| 20:37 |
|
whartung |
so, not everything should be piled in to the URL. |
| 20:37 |
|
whartung |
and at the same time, the URL name is not the sole component of a request |
| 21:38 |
|
Blackskyliner |
whartung, but only as long as I keep to standarised Headers, as the extension of the HTTP Header definitions could be made but are - at least tahts what I got from the summary of fieldings thesis - bad practice. So for things I could not express through Headers I may use additional URI attributes (like GET Params) as long as they are the same for all possible accessing users, or better not dependent on some authorization or no-cache |
| 21:38 |
|
Blackskyliner |
implying state. Did I get this right? |
| 21:56 |
|
whartung |
I talk a bit about this here: http://stackoverflow.com/questions/1296421/rest-complex-applications/1297275#1297275 |
| 22:01 |
|
Blackskyliner |
will read this when I get up today (its like 00:00 AM here at my place), thanks for the article. |
| 22:04 |
|
whartung |
okey dokey |
| 22:05 |
|
|
quimrstorres joined #rest |
| 22:07 |
|
|
fuzzyhorns joined #rest |
| 22:41 |
|
|
Coldblackice joined #rest |
| 23:06 |
|
|
quimrstorres joined #rest |
| 23:54 |
|
|
fuzzyhorns joined #rest |
