dhis2-devs-core team mailing list archive

[Morten Olav Hansen <mortenoh@xxxxxxxxx>]

Maybe not. I feel like many times it will be OK.. but there are still stuff
in response you probably want to look at... an example would be creating a
new object.. and then we can have EntityWebMessageResponse (which would
expose idObject properties of newly created object), so one would know
generated UID etc..

--
Morten

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

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