greptilian logo

IRC log for #rest, 2016-09-05

#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:10 al_nz1 pdurbin: yeah I get it now - it defines the part of the URL that the client is to access?
00:14 fuzzyhorns joined #rest
00:51 tonyacunar joined #rest
00:54 pdurbin yeah
01:08 al_nz1 SO this guy : http://stackoverflow.com/questions/33784552/exchange-web-services-java-api-restful-push-notifications-listener is actually creating a mini webserver (aka listener) that responds to POST message sent as HTML?
01:08 al_nz1 XML I mean
01:56 tonyacunar joined #rest
02:19 tbsf joined #rest
03:18 tbsf joined #rest
03:38 GriffinHeart joined #rest
03:54 tbsf joined #rest
04:03 tbsf joined #rest
04:27 sp1rs joined #rest
05:45 wsiqueir-bbl joined #rest
09:34 Tomatosoup- joined #rest
10:35 jfg9 joined #rest
10:36 jfg9 hi all
10:36 jfg9 What's the best way to POST json to an API without using the application/json content-type header? I want to ensure that a CORS preflight is not triggered. Is the best way to use the text/plain header?
10:36 jfg9 (I'm talking about doing a POST from javascript in a user's browser)
10:39 trygvis I would try another place
11:07 jfg9 Oh right ok
13:20 Macaveli joined #rest
13:40 tonyacunar joined #rest
13:42 tonyacunar joined #rest
14:17 sp1rs joined #rest
14:20 sp1rs joined #rest
14:22 sp1rs_ joined #rest
14:25 sp1rs joined #rest
14:41 _ollie joined #rest
14:54 tonyacunar joined #rest
14:55 sp1rs joined #rest
15:33 Macaveli joined #rest
15:47 Haudegen_ joined #rest
15:48 upasana joined #rest
15:48 riddle joined #rest
15:49 fuzzyhorns joined #rest
16:18 Tomatosoup- joined #rest
16:37 tonyacunar joined #rest
16:45 event15 joined #rest
17:07 foist joined #rest
17:24 wsieroci joined #rest
18:25 sp1rs joined #rest
18:41 sp1rs joined #rest
19:26 Tomatosoup- joined #rest
19:31 Macaveli joined #rest
19:53 Coldblackice joined #rest
20:06 Haudegen joined #rest
20:07 _longines_ joined #rest
20:31 Coldblackice_ joined #rest
20:59 jfg9 joined #rest
21:17 fuzzyhorns joined #rest
21:56 tbsf joined #rest
22:20 k_j joined #rest
22:20 k_j hi
22:21 tonyacunar joined #rest
22:23 k_j how would you monitor a resource if not using long polling GET's on api/resource/events ?       but if this is the only reasonable solution , then those GET are not idempotent, as each one would consume one event (do not consider adding  DELETE please),  therefore the API is not restful
22:25 asdf oh, the client can be smarter than that, by adding a filter to the GETs
22:25 asdf imagine eg. /events?from=12:00, then it looks what time the latest event received was, and the next call is /events?from=12:15
22:28 k_j asdf, yes but that is not idempotent...  say, now you get 2 events, after one hour you might be getting 3 events  , should not GET be idempotent no matter what value of the filter you use?
22:28 k_j asdf, I mean the problem is still the same
22:28 asdf oh? idempotency doesn't mean that the response can never change ever
22:29 asdf indeed, if the state of a resource never changed, then the api wouldn't be very useful :)
22:29 k_j yes, you are right, being idempotent mean a GET *itself* won't change the status, but does not forbid a post to change it
22:31 k_j asdf, another slightly different question:   suppose you have  /api/resource/ . supporting GET's.    can a POST to /api/resource/at/different/url/  change the status of the resource as seen by the first url?
22:34 k_j basically can two urls map to the same resource , can a post to one url change the representation at the other url being the same resource after all?
22:34 asdf oh, why would you have two urls to the same resource?
22:34 Tomatosoup- k_j: thats redundancy
22:35 k_j ok. real case. let me formulate the problem.
22:39 k_j I have /api/default-settings representing a resource (settings of the program).    now   I want to allow the user to modify by overriding  these default settings during a session, in different steps, during the time.   I see this as a series   of POST   to ,say, a resource /api/session/  . each POST maps to a command accepting a subset of default settings. when applied this subset would accordingly modify /api/default-settings too .
22:40 asdf why can't the user modify /api/default-settings directly?
22:41 Tomatosoup- during a session? rest api should be stateless; that means that it should not rely on session
22:43 k_j asdf, the problem is that it is more obvious to start with a copy of the default settings, initially, and propose the relevant subset when the user advances in the session
22:43 k_j Tomatosoup-, not user session, resource session, the term I used might be misleading
22:44 asdf ok, so if the user is changing their session, that also needs to change the default? huh!
22:44 asdf i think i'd have it as separate calls, really: one to your own session, and one to the default settings (if you want to also change the default)
22:44 k_j asdf, yes...
22:45 k_j asdf, so in your opinion it would be better to start a session with a *copy* of the default settings and only allow the user to override this copy, whose setting will be lost next time.
22:46 asdf right, and if the user wants to also change the default, have it be a separate call
22:46 k_j ok
22:47 asdf i mean, i imagine you have a textbox or something in your UI, and next to it there's a checkbox saying "make this the new default"?
22:48 k_j asdf, yes, that is a good  idea
22:49 asdf oh, just asking, no idea if that would work for your program
22:50 k_j asdf, yes it would work
22:50 k_j makes sense
22:53 asdf btw Tomatosoup- makes a fair point; while the application of course is stateful, the communication needs to be stateless - so this "session" doesn't have to do with the actual protocol, right?
22:54 asdf so, silly example, if you update your 'session' with uppercase=true, and now all the other resources are uppercase: that's bad and not restful at all
22:54 asdf but if you mean 'session' is a business level object, then sure
22:55 k_j yes it's a businness level object
23:20 tonyacunar joined #rest
23:21 fuzzyhorns joined #rest
23:26 tbsf joined #rest
23:47 tbsf 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.