Zoom validations

[Julie-House]

When adding a webinar registration I got an error: 'Validation Failed'. I eventually tracked it down to an invalid email address. (full-stop immediately after the @)

When the Zoom API specifies a max-length for params does it spit it back if the length is exceeded, or does it just trim the input?

My thinking is that if it's going to spit it back (with the ever helpful Validation Failed message) then perhaps ZoomNet should look at implementing those validations itself so users of it won't fall foul of this issue. My only concern with implementing the validations is if Zoom ever change them (lengthen or shorten the requirement). But it would still be easier to update ZoomNet once, rather than all projects that use it!

When it comes to email addresses it's not something I want to get into validating. We've tried it before and there's always an edge-case somewhere so I'd rather leave it to Zoom. However, if the error message is that unhelpful then I'm probably going to have to do something!

[Jericho]

You are absolutely correct that, currently, ZoomNet does not validate the input provided and the validation is delegated to the Zoom API. Before I present why I made this decision (and debating whether it was the right decision!), let me just describe how ZoomNet behaves when an error occurs, there may be information in there that might be useful to you.

ZoomNet error handling

When the Zoom API returns an error code, ZoomNet throws a ZoomException and attempts to give you as much details as possible about what just occurred. Specifically, you can catch the exception and review the following properties:

• StatusCode: this property is simply the HttpStatusCode of the response to your request to the Zoom Api. Most of the time it's something very generic like HttpStatusCode.BadRequest (AKA HTTP 400) for example, but sometimes the Zoom documentation can give you more details to explain why you are getting this error. For example: if you are trying to add a registrant to a webinar and the response is HttpStatusCode.Ambiguous (AKA HTTP 300), the Zoom documentation says there are three possible validations that failed and caused this exception:

HTTP Status Code: 300
Invalid webinar ID.
Invalid parameter: occurrence_ids.
Invalid user name.

• Message: this is the error message included in the response received from the Zoom API. Typically, the response from the Zoom API will contain JSON that looks like this:

{
    "code": 300,
    "message": "This meeting has not registration required: 544993922"
}

In this example, the 'Message' property will contain "This meeting has not registration required: 544993922". In your scenario, it sounds like you are, unfortunately, getting a very vague message like "Validation failed".

Edit 2020-01-22: the error code has been added to the ZoomException class in ZoomNet 0.17.0.

• ErrorCode: this is a Zoom-specific numerical code (300 in my above example) which can be useful in some scenarios. For instance, when adding a registrant to a webinar and the response is HTTP 400, the documentation describes the 5 possible error codes and a brief description for each.

• DiagnosticLog: this human readable string contains additional information provided to you by ZoomNet. It includes, among other things, the URI of the request that was attempted (including querystring parameters), headers that were included in the request, the content (if any) that was posted, the content of the response, etc. Please note: the "authorization" request header is voluntarily obfuscated to avoid leaking sensitive information.

• ResponseMessage: this is the actual HTTP response. For debugging and problem solving purposes, I personally find the human-readable DiagnosticLog more useful but you may disagree and you may prefer to review the actual HTTP response. Maybe there's information buried somewhere in the response that might help you figuring out the source of a problem.

Hopefully some of the information I just presented is helpful.

Should validation be done client-side or server-side?

This question, I'm sure, has been debated ever since developers started interacting with APIs. I don't know that there is a right or wrong answer but everyone has their opinion in this topic. Personally, I had to interact with a lot of APIs in my career and I have asked myself this question countless times. Earlier in my career I had a tendency to perform validation on the client-side because I felt it gave me more control but I faced several situations where the server-side logic would be updated and my client-side validation logic would no longer match which resulted in bugs, headaches, etc. That's the reason why at a certain point several years ago I changed my opinion and my current stance on this topic is that it's preferable to simply rely on the server-side logic. Generally, the argument in favor of client-side validation is: why allow a request to be sent to an API (which can be costly, it's a waste of resource and time, etc.) when this request will predictably fail. I sympathize with this point of view but in this case we are dealing with a 3rd party (Zoom in this case) which could decide at any moment to change their logic and they may or may not advertise the change so it can be difficult for us to keep up.

Having said all this, I fully realize that we are debating opinions and everyone has their own view. I'm willing to keep an open mind and I can be persuaded to change my mind if there's a consensus that ZoomNet should perform more validation.

[Julie-House]

Thank you for the in-depth reply. I sympathise with your predicament which is why I logged this as a discussion.

Returning the actual error code would be very helpful. In this instance it wasn't listed as a possible error return, but maybe those are listed elsewhere in the documentation. And, it states that the only validation done at this point is a max-length which is clearly not the case! So it could be the case that they haven't updated the docs since changing the requirements. As you say, they can change at a moments notice and that could mess up a lot of people.

I will look into actually checking for errors - I'm sure that will help a lot!

[Jericho]

I added the ErrorCode to the ZoomException class (See #87). I also edited my comment above to reflect the fact that this information is now available.