Maybe not. I feel like many times it will be OK.. but there are still stuff in response you probably want to look at... an example would be creating a new object.. and then we can have EntityWebMessageResponse (which would expose idObject properties of newly created object), so one would know generated UID etc..
-- Morten On Fri, Oct 17, 2014 at 8:35 PM, Morten Olav Hansen <[email protected]> wrote: > What about this, we have 3 statuses: > > OK, // everything OK > ERROR, // request failed > RESPONSE // see response for more info > > -- > Morten > > On Fri, Oct 17, 2014 at 8:30 PM, Morten Olav Hansen <[email protected]> > wrote: > >> Data values are a bit different... i.e. if you send one value.. and >> overwrite an old value.. it would make sense to send a response back saying >> "replaced old value XX with YY" or something.. we should be better at this.. >> >> -- >> Morten >> >> On Fri, Oct 17, 2014 at 8:29 PM, Bob Jolliffe <[email protected]> >> wrote: >> >>> OK. Sorry I am thinking more of posting datavalues than metadata. In >>> which the outcome is not so binary. >>> >>> On 17 October 2014 14:26, Morten Olav Hansen <[email protected]> wrote: >>> >>>> Hi Bob >>>> >>>> Actually... I think for 95% of the cases.. we only need a yes / no >>>> response, think about usual use-cases.. create a new data element: OK / NOT >>>> OK, enroll a person into a program: OK / NOT OK, delete a chart: OK / NOT >>>> OK >>>> >>>> Most people will not do bulk imports (where this will be visible) >>>> >>>> >>>> -- >>>> Morten >>>> >>>> On Fri, Oct 17, 2014 at 8:25 PM, Bob Jolliffe <[email protected]> >>>> wrote: >>>> >>>>> Looking at what I wrote again. Perhaps I am mixing the meaning of >>>>> status with code. >>>>> >>>>> It seems fine to have a status of OK or ERROR followed by a code which >>>>> can indicate the nuances of how ok it actually was. >>>>> >>>>> On 17 October 2014 14:22, Bob Jolliffe <[email protected]> wrote: >>>>> >>>>>> Hi Morten >>>>>> >>>>>> Looking good ... >>>>>> >>>>>> I think the ability to easily distinguish between good (all ok) >>>>>> imports and not-so-good (some conflicts) responses is really important, >>>>>> as >>>>>> I imagine these will be the most common cases which clients will have to >>>>>> discriminate between. I am not sure if burying the detail too far inside >>>>>> the response body is necessarily the best - but of course it can work. I >>>>>> would lean in favour of some sort of PARTIAL_OK status. >>>>>> >>>>>> It might be helpful to consider (and start to enumerate) the kind of >>>>>> error messages we actually expect to get and classify them. >>>>>> >>>>>> There are the 5xx and 4xx type of http errors which I presume we also >>>>>> want to return such a message, using the mimetype requested by the >>>>>> client. >>>>>> >>>>>> Then there are the 2xx series of messages ie. messages which are >>>>>> deemed OK from an http perspective but can result in a variety of >>>>>> responses >>>>>> from the application perspective (everything fine, some thing fine, >>>>>> incorrect dataset for orgunit, "conflicts" etc). I guess these are what >>>>>> you are thinking of creating 200xx codes for? >>>>>> >>>>>> On 17 October 2014 14:11, Morten Olav Hansen <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Yes, mark... or we can (which might be a better choice) use status = >>>>>>> OK for this, and then have a ImportWebMessageResponse body.. with >>>>>>> additional information.. <response type="type" /> have types.. so we can >>>>>>> define them in the docs, and then the end user client can handle them >>>>>>> accordingly.. >>>>>>> >>>>>>> Because, the import itself was ok.. but there was a few conflicts.. >>>>>>> it would be a bit cleaner to just have OK / ERROR. >>>>>>> >>>>>>> (Halvdan, please use reply-all) >>>>>>> >>>>>>> I think this should be left in the response part of the message.. >>>>>>> and there we can have anything.. >>>>>>> >>>>>>> -- >>>>>>> Morten >>>>>>> >>>>>>> On Fri, Oct 17, 2014 at 8:10 PM, Halvdan Grelland < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> It might be a verbose and slightly complex solution, but we could >>>>>>>> allow status: multistatus with a mandatory per-object status >>>>>>>> description >>>>>>>> (OK or error). Actual warnings are better put in the message fields, >>>>>>>> no? >>>>>>>> >>>>>>>> >>>>>>>> Den fredag 17. oktober 2014 skrev Morten Olav Hansen < >>>>>>>> [email protected]> følgende: >>>>>>>> >>>>>>>>> I'm not a fan of success, but if everyone agrees.. I will change ;) >>>>>>>>> >>>>>>>>> Another issue is.. do we need WARNING? are you all probably know.. >>>>>>>>> if you import a big metadata chunk.. and 50 items are ok.. and 10 not >>>>>>>>> ok >>>>>>>>> (some kind of conflict), we can't return ERROR.. since we did save a >>>>>>>>> lot.. >>>>>>>>> but returning OK / SUCCESS also feels weird.. OK_WITH_WARNING? OK? >>>>>>>>> >>>>>>>>> We have the same issue in data value import.. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Morten >>>>>>>>> >>>>>>>>> On Fri, Oct 17, 2014 at 8:00 PM, Halvdan Grelland < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> This looks nice! >>>>>>>>>> >>>>>>>>>> If the status enum is changed to "success" / "error" this format >>>>>>>>>> would actually be backwards compatible with the (weak) convention in >>>>>>>>>> a lot >>>>>>>>>> of our older frontend code. Might make integrating older code with >>>>>>>>>> the web >>>>>>>>>> api slightly less painful? >>>>>>>>>> >>>>>>>>>> Den fredag 17. oktober 2014 skrev Morten Olav Hansen < >>>>>>>>>> [email protected]> følgende: >>>>>>>>>> >>>>>>>>>> Hei everyone >>>>>>>>>>> >>>>>>>>>>> A few days again, I committed a new class called WebMessage. The >>>>>>>>>>> point of this class is to have a common building block for all kind >>>>>>>>>>> of >>>>>>>>>>> responses from the web-api. >>>>>>>>>>> >>>>>>>>>>> The main properties are: >>>>>>>>>>> WebMessage: >>>>>>>>>>> status: OK / ERROR >>>>>>>>>>> code: internal code >>>>>>>>>>> httpStatusCode: http status code >>>>>>>>>>> message: non-technical end-user message (i18n etc) >>>>>>>>>>> devMessage: technical / debug message >>>>>>>>>>> response: WebMessageResponse, can be anything >>>>>>>>>>> >>>>>>>>>>> So a typical response can be: >>>>>>>>>>> >>>>>>>>>>> JSON: >>>>>>>>>>> { >>>>>>>>>>> status: "OK", >>>>>>>>>>> code: 20001, >>>>>>>>>>> httpStatusCode: 200 // notice that code also starts with 200 >>>>>>>>>>> message: "DataElement successfully saved.", >>>>>>>>>>> devMessage: "DataElement was successfully saved to database, >>>>>>>>>>> id ID123" >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> XML: >>>>>>>>>>> <webMessage xmlns="http://dhis2.org/schema/dxf/2.0"; status="OK" >>>>>>>>>>> code="20001" httpStatusCode="200"> >>>>>>>>>>> <message> DataElement successfully saved .</message> >>>>>>>>>>> <devMessage> DataElement was successfully saved to database, >>>>>>>>>>> id ID123 </devMessage> >>>>>>>>>>> </webMessage> >>>>>>>>>>> >>>>>>>>>>> And of course, response can be added... its just a simple >>>>>>>>>>> interface, with nothing on it. so you can create your own >>>>>>>>>>> implementations >>>>>>>>>>> (I only provide one, ImportCountWebMessageResponse) >>>>>>>>>>> >>>>>>>>>>> This class is not currently in use, but I'm planning to >>>>>>>>>>> implement this full-scale in 2.18, so I'm very open to any kind of >>>>>>>>>>> comments >>>>>>>>>>> (unless you are living under a rock, you will be starting to see >>>>>>>>>>> this >>>>>>>>>>> messages all the time), so please.. this is the time to change this >>>>>>>>>>> format >>>>>>>>>>> (it will be fixed from 2.18). >>>>>>>>>>> >>>>>>>>>>> Comments? >>>>>>>>>>> >>>>>>>>>>> httpStatusCode can definitely be left out, but it just >>>>>>>>>>> simplifies things a lot to leave it in.. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Morten >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mailing list: https://launchpad.net/~dhis2-devs-core >>>>>>> Post to : [email protected] >>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs-core >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
-- Mailing list: https://launchpad.net/~dhis2-devs-core Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs-core More help : https://help.launchpad.net/ListHelp
