Of course.. one might think like this also.. OK == skip response body, doesn't matter.. it was OK, ERROR = check response body, additional comments there (validation etc)
-- Morten On Fri, Oct 17, 2014 at 8:26 PM, 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
