Rails 4 introduced the concept of Strong Parameters, a way to whitelist incoming parameters for a given write operation. The folks at Zendesk took it a step further with Stronger Parameters, which added type-checking to the strong parameter checks.
This works well for traditional REST endpoints that can put the logic in
the controller. But JSONAPI Suite endpoints can “sidepost” objects at
multiple endpoints - we might save a Person at the /people endpoint,
but also sidepost from the /accounts endpoint. The strong parameters
logic would need to be duplicated across controllers.
Enter Strong Resources. Define whitelist templates in one place, and re-use them across your application:
Now, whenever we POST or PUT to /accounts, the request
attributes must come in this format. If an extra attribute is given -
perhaps a read-only rate_limit attribute - the request will be
rejected. If active comes in as a string instead of a boolean, the
request will be rejected.
Let’s sidepost a Person record to the /accounts endpoint:
We can now sidepost Person records - via the people relationship -
to the /accounts endpoint. If the Person attributes don’t match the
:person strong resource template, the request will be rejected.
By default, we only allow create and update of associations, but you
can opt-in to destroy and disassociate as well:
There are a variety of ways to customize strong resource templates -
like allowing certain parameters only on update but not create. Head
over to the strong_resources documentation for a more in-depth
overview.
Note: a common issue is allowing an input to be null. You can define your own types, or