Just add a parameter to the current URI's GET
It's pretty typical to use a URI's for multiple actions.
If you're talking about the same resource but a different action, you'd define it as a parameter.
Then where you define your GET method you detect the presence of the print parameter and handle it differently.
REST is defined in the following way:
- POST - Create a record, asset, or resource
- PUT - Update, a record, asset, or resource
- DELETE - Remove a, record, asset, or resource
GET, on the other hand, is meant to be used in multiple ways because there are typically a lot of different forms that a resource may be retrieved. That's also why GET requests are represented as a query string. If you were working with a database resource you'd literally be retrieving a view via a query but REST is intentionally abstracted to a higher level because it's designed to handle with many different types of resources.
The REST specification is pretty forward thinking, even though API's are only recently starting to use it heavily.
If you're interested in learning more about REST protocols I highly suggest you read "Haters Gonna Hate HATEOAS".
@Shauna pointed out an interesting hole in my reasoning. There's no true right way and many forms are considered acceptable. I thought about it some more and since your intended use is to transform the data into a different representation, it makes sense to define the transform as a new MIME-Type.
For example, you could represent the URI as:
Where you could set the response Content-Type to text/html+print. That way you'd also have the option to define more transforms in the future.
// for application/json
// for application/atom+xml
Either way, all forms are acceptable. The implementation you decide depends more on personal preference, and the capabilities of your server.
Aside: Let me clarify since there seems to be some confusion. The 'print' query-parameter and/or content-type is used to specify how the resource is transformed. Not how to trigger a physical print job. For security reasons, hardware-level access is always left to the user/client/browser.