dhis2-devs-core team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

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
>
>