Error Messages

[steffilazerte]

@pmorrill This is a bit of an extension of #12.

Right now if the server returns an error message, it looks like it also returns all the data associated with the filters which didn't have any errors (at least it does this for DOY).

Would it be possible to stop and return no data, as an error in a filter could result in a much larger set of data than anticipated?

[pmorrill]

I will look. Should be possible. I am not on BSC work this week much but next week will be more productive.

[steffilazerte]

For example, right now for the BMDE fields (https://sandbox.birdscanada.org/api/metadata/bmde_fields) If you don't provide a version, it returns an http 500 error, which is emphatic :) and makes it easier to highlight errors.

[steffilazerte]

And finally (sorry for the spam), perhaps we could consolidate the error message names? i.e. for the first example (an error message, returns HTTP 200 status), the error message is called errorMsgs, but in the second example (an error message, returns HTTP 500 status), the error message is called Error_msg.

Unless there's a reason for this that I'm not aware of?

[pmorrill]

I have now normalized this: all errors msgs will be returned as errorMsgs list. Also, errors validating the filter attributes now cause abort of the query, and return the error.

[steffilazerte]

@pmorrill, Just to wrap this up, it looks to me as if all messages are returned as a "ErrorMsgs" list (capital E). Is this the final name? R is case sensitive and I use this list to pull out the message, so I just want to make sure it won't change :)

[pmorrill]

On consideration, I have switched the 'errors' return structure to use camel case, since that is what the rest of the system uses. So, the structure will be:

{ "entryPoint" : String "error": integer (the http error code, also present in the header) "errorMsgs" : [ list of Strings ] }

This change will be in next deployment.

[steffilazerte]

Great, made my fixes and this is good now.