greptilian logo

IRC log for #rest, 2015-07-17

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.

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

All times shown according to UTC.

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

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

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.