COOPS Metadata for All Product Types

[SorooshMani-NOAA]

COOPS web API seems to just return waterlevel stations when nothing is explicitly asked for in the parameters. We need to return all stations in the searvey API. See:
https://api.tidesandcurrents.noaa.gov/mdapi/prod/#Type

To further elaborate:
The current state of COOPS web API means that when a user tries to get the list of all the stations, searvey needs to hit the COOPS servers with multiple requests.

This also brings up the question about the rate limit for COOPS servers for either data and metadata.

To be more specific, ideally we'd like to be able to get all the stations using something like:

https://api.tidesandcurrents.noaa.gov/mdapi/prod/webapi/stations.json?type=all

which is currently an error. The error states all valid types of stations:

{"errorMsg":"Invalid type specified: valid options are one of the following: waterlevels, waterlevelsandmet, airgap, datums, supersededdatums, benchmarks, supersededbenchmarks, historicwl, met, harcon, tidepredictions, currentpredictions, currents, historiccurrents, surveycurrents, cond, watertemp, physocean, tcoon, visibility, 1minute, historicmet, historicphysocean, highwater, lowwater, hightideflooding, ofs, partnerstations","errorCode":400}

[SorooshMani-NOAA]

@AtiehAlipour-NOAA this is the ticket related to station issue we talked about

[AtiehAlipour-NOAA]

@SorooshMani-NOAA, thank you for tagging me in this ticket. Please let me to talk to Armin and see what he suggests. Thanks!

[SorooshMani-NOAA]

Thank you @AtiehAlipour-NOAA for following up. To summarize:

[COOPS] do[es] not provide a single API that can retrieve all types of stations. Users need to explicitly request the list of stations they are interested in. The reason for this is that different types of stations have different types of data and formats, so this is the optimal way of obtaining data for most of their users.

and

[COOPS] server can easily handle 100 calls per second, so there shouldn't be any [rate] issues

also

it would be much easier to write a wrapper [... private API] might be feasible but involves too many logistics