Why is this different than other ones?

@Meldiron Raised a good point that some workflows require creating multiple documents at once and we don't want to be too limiting to client apps, especially when the change is already reducing the amount of requests they can make.

@abnegate, @Meldiron, since the abuse key is the URL, this would allow creating 120 documents in 1 collection in 1 minute, right? Is that reasonable?

Also, after reviewing the abuse check a bit more, it looks like params are part of the abuse check so wouldn't a bad actor be able to change the param value to bypass the abuse check?

@stnguyen90 What is reasonable is open for discussion - what are your thoughts?

We can configure the key to be whatever we want: URL, IP, any of the params, or a combination of all.

The block you referenced lets us explicitly set request params as a part of the key - if we don't use them, it won't have any effect. For example, the abuse key for creating a magic URL contains the userId, but none of the other params:

    ->label('abuse-key', 'url:{url},userId:{param-userId}')

@abnegate,

What is reasonable is open for discussion - what are your thoughts?

1 doc in a particular collection per second should be plenty, right?

The block you referenced lets us explicitly set request params as a part of the key

I see now! Thanks for the clarification!

@stnguyen90 Please check the refactor here and lets follow up there: #3741

1 doc in a particular collection per second should be plenty, right?

From further investigation today, URL keys are not populated with ID's, however, the route method was not taken into account which led to limits applying across PATCH/PUT/DELETE routes with the same URL. Following the refactor, keys will look like this:

cc @eldadfux