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
