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
