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
