dhis2-devs-core team mailing list archive

[Morten Olav Hansen <mortenoh@xxxxxxxxx>]

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 <halvdanhg@xxxxxxxxx>
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 <mortenoh@xxxxxxxxx>
> 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
>>
>