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
