dhis2-devs-core team mailing list archive

[Morten Olav Hansen <mortenoh@xxxxxxxxx>]

Sure, but do we really want the end-user client to handle all these http
codes? Also, 207 sounds a bit esoteric, I don't think many people knows
about this... honestly, most of our target audience doesn't even know what
REST is..

--
Morten

On Fri, Oct 17, 2014 at 8:16 PM, Dan <dcocos@xxxxxxxxx> wrote:

> There is an HTTP code 207 which returns multiple statuses.
>
>
> On Oct 17, 2014, at 9:11 AM, 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
>
>
>