Allowing optional extended fields in UWS job listings
Stelios Voutsinas
SVoutsinas at lsst.org
Wed Jul 16 19:00:10 CEST 2025
Hello all,
I'd like to raise a question I've also posted as an issue to the UWS repo here:
https://github.com/ivoa-std/UWS/issues/5
The current UWS spec limits job listings (/{jobs}) to basic fields in ShortJobDescription (phase, runId, ownerId, creationTime, id).
Essential information like the query text or start/end time, and parameters requires separate API calls to /{jobs}/{job-id}, creating N+1 query patterns that hurt performance for clients that may want to use the job list to display a user's query history.
This basically leads clients to have to decide between showing incomplete job lists or making individual job requests for every job in the list to display meaningful information that helps user identify a job.
My proposal is to extend the specification to optionally include additional fields from JobSummary in job listings.
This could be implemented through optional schema elements, or if for some reason that breaks compatibility for clients, perhaps an alternative could be using query parameters (GET /{jobs}?include=startTime,endTime,parameters).
This would allow clients to use the job listing endpoint as a source of a user's job history and do so efficiently without requiring extra hops to gather additional metadata that is critical to identify each job.
The motivation for this is that we use the job listing as a way of providing a user their TAP query history, but have found that the way the current job list schema is specified we have to make the additional HTTP hops for each job which leads to significant traffic increase to our server as the number of users starts to scale up.
Any thoughts on this?
Stelios Voutsinas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dsp/attachments/20250716/9790f260/attachment.htm>
More information about the dsp
mailing list