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
