Add pagination, docs, and better tests for Rules

[joshcanhelp]

• Add pagination to getAll method in Rules
• Throw CoreException for missing or empty required params in get, create, update, and delete
• Rewrite tests for more isolation and better coverage

[cocojoe]

Can you make your errors consistent? In the create method you have
Missing required "script" field.
in this one it's
Empty "data" parameter; nothing to do.

If it's empty or invalid it's still invalid, as these are essential I would just have something simple like
{param} is missing

[joshcanhelp]

It's indicating 2 different things. In create, we require 2 specific fields in that $data array to create a Rule. In update, we don't require any specific fields but if it's empty then there is no reason to send the request. The error messages reflect that.

[lbalmaceda]

Jumping in here.

1. Empty or invalid "id" parameter. I agree with martin. That's "invalid" anyway. You can have a helper function somewhere that receives the value and the name of the parameter like I do and so keep a universal message like "Invalid {param name} parameter" somewhere.

2. For the PATCH I know it makes no sense at all to make the call if the value is empty, but it's not that the call will fail with an error from the server. AFAIK It just won't do anything. Anyway, I also agree messages should be similar. If you are going to consider this an error scenario then just use the same message as in (1).

An alternative for (2) however is, knowing in advance the $data is empty, you can just log a message (not throw an exception) and avoid making the request. How does that sound?

[joshcanhelp]

Thanks for the discussion here but I still don't see this as being inconsistent. I'm fine with changing Empty or invalid to just Invalid but where the message is different, the condition is different as well.

• For get, delete, and create, the ID parameter needs to have a value (not null or "") or it's empty. It needs to also be a string (not [12345678] or SomeClassName) or it's invalid. Again, I'm fine with changing the exact wording.
• For create, that forces an array to be passed so we know the type is right. But there are 2 specific keys/fields that it needs. If I say Invalid $data parameter, then I'm leaving out helpful information for debugging. I could say Invalid $data parameter ("name" and "script" keys are required) ... does that seem more consistent to you guys?

[joshcanhelp]

@cocojoe - Updated exception language and removed the one for update

[cocojoe]

Errors look better, although you should think about unifying the errors generated. So have a function that you just pass a value and returns the standardised text etc

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.