Time  Nick        Message
22:55 k_j         yes it's a businness level object
22:54 asdf        but if you mean 'session' is a business level object, then sure
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: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:50 k_j         makes sense
22:50 k_j         asdf, yes it would work
22:49 asdf        oh, just asking, no idea if that would work for your program
22:48 k_j         asdf, yes, that is a good  idea
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:46 k_j         ok
22:46 asdf        right, and if the user wants to also change the default, have it be a separate call
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:44 k_j         asdf, yes...
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 asdf        ok, so if the user is changing their session, that also needs to change the default? huh!
22:43 k_j         Tomatosoup-, not user session, resource session, the term I used might be misleading
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:41 Tomatosoup- during a session? rest api should be stateless; that means that it should not rely on session
22:40 asdf        why can't the user modify /api/default-settings directly?
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:35 k_j         ok. real case. let me formulate the problem.
22:34 Tomatosoup- k_j: thats redundancy
22:34 asdf        oh, why would you have two urls to the same resource?
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: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: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:29 asdf        indeed, if the state of a resource never changed, then the api wouldn't be very useful :)
22:28 asdf        oh? idempotency doesn't mean that the response can never change ever
22:28 k_j         asdf, I mean the problem is still the same
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: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:25 asdf        oh, the client can be smarter than that, by adding a filter to the GETs
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:20 k_j         hi
11:07 jfg9        Oh right ok
10:39 trygvis     I would try another place
10:36 jfg9        (I'm talking about doing a POST from javascript in a user's browser)
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        hi all
01:08 al_nz1      XML I mean
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?
00:54 pdurbin     yeah
00:10 al_nz1      pdurbin: yeah I get it now - it defines the part of the URL that the client is to access?