Querying services for classes of object, returning multiple targets

[talister]

Is your feature request related to a problem? Please describe.
As FOMO developers, @carrholt and I find ourselves developing two services which query two services at JPL, both of which returns many small body designation, along with parameters, which could be could be turned into Targets within FOMO. The two services are:

1. JPL Small Body DB Query (and associated API) - this allows for querying of broad classes of small bodies (e.g. NEOs, asteroids, comets) with optional selection by class (e.g. Amor NEOs, Jupiter Family Comets) and constraint filtering and output column selection. We plan to use to periodically fetch newly discovered objects e.g. by Rubin, within specific classes of object and follow-up targets
2. JPL Small Body ID Tool (and associated API - this allows querying for all known objects within a given FOV at a particular time and sky location from a particular observation site. This returns a list of small bodies, along with speed, magnitude, distance from FOV center and (optionally) the orbital elements, which could also be turned into new Targets in FOMO. (We plan to use this to find out e.g. what asteroids where within the Rubin ComCam fields during commissioning to try find them in DP1, once it drops)

Describe the solution you'd like
It feels like both of these queries overlap with the other query-making code within the TOM Toolkit for assembling queries, robustly querying the remote service and returning and parsing the results and making model object instances. However it doesn't really fit the AbstractHarvester and derived classes in tom_targets which are single object or GenericBroker on tom_alerts as the JPL services aren't really brokers and these are not really Alerts. It feels closer to the LSST RSP module in tom_dataservices or the (I believe) in-progress refactoring of the TNS broker/harvester.

Additional context
Screenshot of an example setup of the JPL SB ID tool query page and results

[jchate6]

This is definitely something that should rely on tom_dataservices.

Currently #1212 is being used to finalize that app and make sure all of the requisite pieces exist.

What is the priority for adding these data services for FOMO?

[talister]

This is definitely something that should rely on tom_dataservices.

Currently #1212 is being used to finalize that app and make sure all of the requisite pieces exist.

What is the priority for adding these data services for FOMO?

For item 1. (SBDB) which @carrholt is working on, we need it for Rubin operations but it would be very desirable to have at least a MVP by the time of the RCW. For item 2. (SB ID Tool), I want it by next week before DP1 drops on June 30... Carrie and I discussed yesterday and we figured that the best approach is to carry on with getting the code written as semi-standalone code and tests right now as (hopefully) most of the work is in figuring out what we want to query, making general query builders (the very general nestable complex SBDB query constraints that are possible and getting that URIencoded and working looks...sporting..) and parsing results. Hopefully the later refactor to use tom_dataservices won't be too bad but I don't think our immediate needs should necessarily gate toolkit progress and plans.