dhis2-devs-core team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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 <bobjolliffe@xxxxxxxxx> 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 <mortenoh@xxxxxxxxx> 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 <halvdanhg@xxxxxxxxx>
>> 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 <mortenoh@xxxxxxxxx>
>>> 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 <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
>>>>>>
>>>>>
>>>>
>>
>> --
>> Mailing list: https://launchpad.net/~dhis2-devs-core
>> Post to     : dhis2-devs-core@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs-core
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>