| 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 |
