Unrecognised Parameters

[Christopher Gammie]

We currently have a problem that if we are triggering xdebug by sending a XDEBUG_SESSION_START parameter to our api, Parameters::isEmpty() no longer returns true because it includes looking at unrecognised parameters.

We have a related problem in that if a controller does not allow any JSON API defined parameters for a particular route, but does allow unrecognised parameters, Parameters::isEmpty() is useless because it does not distinguish between the parameters that are defined by the JSON API spec and those that are not.

In short, it is questionable whether this package should be checking unrecognised parameters at all because they are not covered by the JSON API spec. I think ParametersInterface::getUnrecognizedParameters() is useful as it is a way of getting all the non-JSON API defined parameters from a request. However, we find that in pretty much every scenario, the logic around unrecognised parameters is completely independent from the logic around the JSON API defined parameters.

So I'd propose the following changes:

1. Modify ParametersInterface::isEmpty() so that it returns true if inclusion, field set, sorting, paging and filtering parameters are empty - but ignore unrecognised parameters. We could add a ParametersInterface::hasUnrecognizedParameters() method for checking those, or just leave it to the code to check whether the value returned by getUnrecognizedParameters() is empty or not. RestrictiveQueryChecker needs to have the allowUnrecognizedParameters removed because logic around unrecognised parameters is independent of logic around JSON API defined parameters.
2. Leave ParametersInterface::isEmpty() as it is, but add a method for checking whether the JSON API defined parameters are empty. The problem with this though is when automating checking e.g. in limoncello doing $this->checkParametersEmpty() what is the controller asking to do - check only the JSON API defined ones or unrecognised as well?

Our preference is (1) - we don't feel that this package should be handling unrecognised parameters because they are outside of the scope of JSON API. Providing a way to get the ones that aren't covered by the spec is useful, but checking whether they are allowed in RestrictiveQueryChecker is causing problems because the logic around whether they are allowed in different scenarios is far too complex to sum up in a simple boolean.

[neomerx]

I'm fine with (1). If you don't need hasUnrecognizedParameters I think it shouldn't be there until it's needed.

[Christopher Gammie]

Great, I'll be able to put some code together at some point this week.

[Christopher Gammie]

@neomerx

I've pushed a feature/issue89 branch.

Removing the logic for isEmpty() checking unrecognized parameters is straightforward. Removing unrecognized parameters checking is quite a major change because it changes the signature of the factory/constructors for the query checkers.

One other option might be to leave in the allowUnrecognizedParameters for the parameters checker, but change the default from false to true. That would be a better interpretation of the spec because the spec doesn't actually say anything about unrecognized parameters so a more literal interpretation of the spec is to say they are allowed by default.

That option would at least leave in the capability of checking unrecognized parameters in case anyone did want to have them checked at the same time as the JSON API defined parameters. However, I think they should be the final argument in the factory/constructor (as they are outside the spec) and I'd suggest rather than being a true/false boolean, it should be like the other parameters - i.e. you pass in a list of unrecognized parameters that are allowed, or disallow all of them.

Not sure what you think about that...! For info I'm on holiday for a week from today so won't be able to look at this again until I get back.

[neomerx]

@lindyhopchris Sorry for delay in response. I haven't got why removing $allowUnrecognized instead of just setting it to true.

[neomerx]

@lindyhopchris isEmpty do not check unrecognized parameters as you proposed. I've put back allowUnrecognizedParameters back as I haven't received any feedback from you however its default value was changed from false to true. I guess it's more consistent with the isEmpty change and meets your expectations as well.

[Christopher Gammie]

@neomerx

Yeah, that's fine - changing the default from false to true is fine, and isEmpty not checking unrecognized parameters.

Sorry for not being very responsive - have been on holiday then totally hectic with other stuff at work.