Introduce client-side validation on methods

[PattaFeuFeu]

In #287 and #286, I started introducing client-side validation for some very easy to catch errors defined by the Mastodon documentation, such as “input length should only be 80 characters”, “input should not contain spaces”, “input should not contain #”, and so on.

We want to go through all existing methods (“methods” meaning the methods in bigbone/src/main/kotlin/social/bigbone/api/method) and check where it could make sense to add client-side validation.

For the client-side validation, we want to return IllegalArgumentExceptions. For easy ones, we should use Kotlin’s require and a message lambda that we pass.

Example:

fun blockDomain(
    domain: String
) {
    require(domain.isNotBlank()) { "domain must not be blank" }

For the slightly harder ones where we deal with optional parameters that may or may not be null, but if they’re non-null need to follow certain criteria, we write our own checks, such as:

if (range.limit != null && range.limit > QUERY_RESULT_LIMIT) {
    throw IllegalArgumentException(
        "limit defined in Range must not be higher than $QUERY_RESULT_LIMIT but was ${range.limit}"
    )
}

---

@PattaFeuFeu I think we should go through all methods and implement these checks everywhere where needed. Let's create a separate issue for this. Any objections?

Originally posted by @andregasser in #287 (comment)

[bocops]

Having seen this in some newly added methods, I wonder if we should really do this everywhere, especially in cases where the server would fail safely, anyway.

For example, any endpoint that accepts a limit parameter will already coerce the given limit to be within the valid range, so any request with an invalid limit value should never fail, but just return less results than expected. This might happen anyway even for a valid limit value (if there simply aren't more results to return), so a library user would need to check the number of returned results anyway.

If these allowed limits ever change, whether it is between Mastodon versions or even by individual instances being configured manually, our library could not be fully used on some instances unless updated.

I do think that this is a good thing to do for cases where we are sure that the request would fail with some 4xx response or at least lead to very unexpected results, like trying to schedule a post in the past or with a string that cannot be parsed into any valid timestamp - but I doubt we should do it all across the board.

[PattaFeuFeu]

For example, any endpoint that accepts a limit parameter will already coerce the given limit to be within the valid range,[…]

Oh, I did not know that! I thought it would fail with a higher limit. That was my whole reason for doing client-side validation: To fail the request before it goes over the network to save resources.

If that turns out to not be the case, I’m also in favour of rolling those checks back.

If these allowed limits ever change, whether it is between Mastodon versions or even by individual instances being configured manually, our library could not be fully used on some instances unless updated.

Yep, excellent point. I did think about that possibility from time to time but never talked about it. Good that you raise it!