Sure, but do we really want the end-user client to handle all these http codes? Also, 207 sounds a bit esoteric, I don't think many people knows about this... honestly, most of our target audience doesn't even know what REST is..
-- Morten On Fri, Oct 17, 2014 at 8:16 PM, Dan <[email protected]> wrote: > There is an HTTP code 207 which returns multiple statuses. > > > On Oct 17, 2014, at 9:11 AM, 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
