dhis2-devs-core team mailing list archive

[Morten Olav Hansen <mortenoh@xxxxxxxxx>]

What about this, we have 3 statuses:

OK, // everything OK
ERROR, // request failed
RESPONSE // see response for more info

--
Morten

On Fri, Oct 17, 2014 at 8:30 PM, Morten Olav Hansen <mortenoh@xxxxxxxxx>
wrote:

> Data values are a bit different... i.e. if you send one value.. and
> overwrite an old value.. it would make sense to send a response back saying
> "replaced old value XX with YY" or something.. we should be better at this..
>
> --
> Morten
>
> On Fri, Oct 17, 2014 at 8:29 PM, Bob Jolliffe <bobjolliffe@xxxxxxxxx>
> wrote:
>
>> OK.  Sorry I am thinking more of posting datavalues than metadata.  In
>> which the outcome is not so binary.
>>
>> On 17 October 2014 14:26, Morten Olav Hansen <mortenoh@xxxxxxxxx> wrote:
>>
>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>