Hey guys, one issues Tadeas identified during testing sender endpoint via Java Sender lib is connected to this quiet change in the REST response from REST Sender endpoint (we added text/plain response specification): https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... As we were always responding with "Job submitted", admin-ui client started to complain about the response not being JSON. So obvious fix was change that to text/plain, right? Not really.. some clients like Java Sender lib already expects application/json and JAX-RS then refuses these requests: https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/... The question is, what should be the correct response? There are many options, I would be perfectly fine with 204 No Content reply,

but JSON might be more appropriate for future extensions, we may want to return e.g. PushMessageInformation#id or something else as part of the response. So, wouldn't be application/json more appropriate than text/plain? We may send empty body now {}. Is this something we want to address for Alpha? Or should we release fixed Java Sender lib?

Cheers, ~ Lukas _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Wed, Apr 29, 2015 at 5:50 PM, Lukáš Fryč <lukas.fryc(a)gmail.com&gt; wrote: > Hey guys, > > one issues Tadeas identified during testing sender endpoint via Java > Sender lib is connected to this quiet change in the REST response from REST > Sender endpoint (we added text/plain response specification): > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... > > > As we were always responding with "Job submitted", admin-ui client > started to complain about the response not being JSON. So obvious fix was > change that to text/plain, right? > > Not really.. some clients like Java Sender lib already expects > application/json and JAX-RS then refuses these requests: > > > https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/... > > > > The question is, what should be the correct response? > > There are many options, I would be perfectly fine with 204 No Content > reply, > 201/accept is the way to go - since the server accepts a job, for further processing.

HOWEVER, I am fine w/ skipping the content "jib submitted" on the beta.1 release

> > but JSON might be more appropriate for future extensions, we may want to > return e.g. PushMessageInformation#id or something else as part of the > response. > > So, wouldn't be application/json more appropriate than text/plain? We may > send empty body now {}. > > > Is this something we want to address for Alpha? Or should we release > fixed Java Sender lib? > if needed, we need an update of the sender lib - I think due to the new format for sending pushes, we anyways need a 1.1.0-alpha.n release of that lib. Perhaps we can have one after the server is out, Sebi?

> > > Cheers, > > ~ Lukas > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hello, It is a good remark! I noticed it when worked on REST api doc generation [1]. In my REST services I always use JSON or empty body and it looks like a pure api. text/plain is not compatible with it. Think, that it will be better to fix it in later releases. [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/526 Best regards, Idel Pivnitskiy -- E-mail: Idel.Pivnitskiy(a)gmail.com Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy> 2015-04-29 18:50 GMT+03:00 Lukáš Fryč <lukas.fryc(a)gmail.com&gt;: > Hey guys, > > one issues Tadeas identified during testing sender endpoint via Java > Sender lib is connected to this quiet change in the REST response from REST > Sender endpoint (we added text/plain response specification): > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... > > > As we were always responding with "Job submitted", admin-ui client > started to complain about the response not being JSON. So obvious fix was > change that to text/plain, right? > > Not really.. some clients like Java Sender lib already expects > application/json and JAX-RS then refuses these requests: > > > https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/... > > > > The question is, what should be the correct response? > > There are many options, I would be perfectly fine with 204 No Content > reply, > > but JSON might be more appropriate for future extensions, we may want to > return e.g. PushMessageInformation#id or something else as part of the > response. > > So, wouldn't be application/json more appropriate than text/plain? We may > send empty body now {}. > > > Is this something we want to address for Alpha? Or should we release > fixed Java Sender lib? > > > Cheers, > > ~ Lukas > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Could I work on this issue? My JIRA account is "idelpivnitskiy". Thanks, Idel 2015-04-30 9:01 GMT+03:00 Lukáš Fryč <lukas.fryc(a)gmail.com&gt;: > We have discussed this a bit this morning at IRC, > > and agreed to use 202 Accepted status code and empty JSON body {} (here > we may later expose ID of the operation). > > Additionally Java Sender lib should be changed to send Accept header > "application-json; text-plain", so that it keeps working with future and > past versions. > > st 29. 4. 2015 v 18:14 odesílatel Idel Pivnitskiy < > idel.pivnitskiy(a)gmail.com&gt; napsal: > > Hello, >> >> It is a good remark! I noticed it when worked on REST api doc generation >> [1]. >> In my REST services I always use JSON or empty body and it looks like a >> pure api. text/plain is not compatible with it. Think, that it will be >> better to fix it in later releases. >> >> [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/526 >> >> Best regards, >> Idel Pivnitskiy >> -- >> E-mail: Idel.Pivnitskiy(a)gmail.com >> Twitter: @idelpivnitskiy <https://twitter.com/idelpivnitskiy> >> GitHub: @idelpivnitskiy <https://github.com/idelpivnitskiy> >> 2015-04-29 18:50 GMT+03:00 Lukáš Fryč <lukas.fryc(a)gmail.com&gt;: >> >>> Hey guys, >>> >>> one issues Tadeas identified during testing sender endpoint via Java >>> Sender lib is connected to this quiet change in the REST response from REST >>> Sender endpoint (we added text/plain response specification): >>> >>> >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs... >>> >>> >>> As we were always responding with "Job submitted", admin-ui client >>> started to complain about the response not being JSON. So obvious fix was >>> change that to text/plain, right? >>> >>> Not really.. some clients like Java Sender lib already expects >>> application/json and JAX-RS then refuses these requests: >>> >>> >>> https://github.com/aerogear/aerogear-unifiedpush-java-client/blob/master/... >>> >>> >>> >>> The question is, what should be the correct response? >>> >>> There are many options, I would be perfectly fine with 204 No Content >>> reply, >>> >>> but JSON might be more appropriate for future extensions, we may want >>> to return e.g. PushMessageInformation#id or something else as part of the >>> response. >>> >>> So, wouldn't be application/json more appropriate than text/plain? We >>> may send empty body now {}. >>> >>> >>> Is this something we want to address for Alpha? Or should we release >>> fixed Java Sender lib? >>> >>> >>> Cheers, >>> >>> ~ Lukas >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev