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
