dhis2-devs-core team mailing list archive

[Morten Olav Hansen <mortenoh@xxxxxxxxx>]

Hi Bob

Actually... I think for 95% of the cases.. we only need a yes / no
response, think about usual use-cases.. create a new data element: OK / NOT
OK, enroll a person into a program: OK / NOT OK, delete a chart: OK / NOT OK

Most people will not do bulk imports (where this will be visible)


--
Morten

On Fri, Oct 17, 2014 at 8:25 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:

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