While I think @Alex is along the right path, conceptually I think it should be the reverse of what is suggested.

The URL is in effect "the resources we are targeting" hence:

 [GET] mail/1 

means get the record from mail with id 1 and

 [PATCH] mail/1 

means patch the mail record with id 1. The querystring is a "filter", filtering the data returned from the URL.

 [GET] mail?markAsRead=true 

So here we are requesting all the mail already marked as read. So to [PATCH] to this path would be saying "patch the records already marked as true"... which isn't what we are trying to achieve.

So a batch method, following this thinking should be:

 mail/?id=1,2,3 <the records we are targeting>  [PATCH] mail[markAsRead]=true 

of course I'm not saying this is true REST (which doesnt permit batch record manipulation), rather it follows the logic already existing and in use by REST.

While I think @Alex is along the right path, conceptually I think it should be the reverse of what is suggested.

The URL is in effect "the resources we are targeting" hence:

 [GET] mail/1 

means get the record from mail with id 1 and

 [PATCH] mail/1 data: mail[markAsRead]=true 

means patch the mail record with id 1. The querystring is a "filter", filtering the data returned from the URL.

 [GET] mail?markAsRead=true 

So here we are requesting all the mail already marked as read. So to [PATCH] to this path would be saying "patch the records already marked as true"... which isn't what we are trying to achieve.

So a batch method, following this thinking should be:

  [PATCH] mail/?id=1,2,3 <the records we are targeting> data: mail[markAsRead]=true 

of course I'm not saying this is true REST (which doesnt permit batch record manipulation), rather it follows the logic already existing and in use by REST.