There's a good architectural principle in web applications that
anything you want to name you should name with a UR*. So, if
you're really thinking of doing this using the web (whether HTTP
or some other future web protocol), then it's probably a good
idea for each job (once submitted) to have its own URL, rather than
its own job-id. (Of course, the URL will probably be
http://printer.name/job/job-id or some such, but the architecture
doesn't have to know that.)
It does make sense to return the status of both the job
and of the printer to which the job has been assigned in
a single get status request, but it also makes sense to
be able to ask a job the URL of the printer it was assigned
to, e.g., if the job failed for printer reasons, to query
the printer more carefully.
I just think you probably will do fine if you worry about the
semantics of the operations rather than the performance of
setup and teardown for operations that occur as infrequently
as print requests.
Larry