levels endpoint in 3.14rc03

[mdstanfill]

Trying out the new CDA 3.14rc03, and the levels endpoint with level-id-mask, e.g.:

curl -X 'GET'
'https://wm.nwp.ds.usace.army.mil:8243/nwdp-data-314rc3/levels?level-id-mask=CGR.%2A&office=NWDP'
-H 'accept: application/json;version=2'

seems to always return JSON with no levels found, whereas the prior version:

curl -X 'GET'
'https://wm.nwp.ds.usace.army.mil:8243/nwdp-data/levels?level-id-mask=CGR.%2A&office=NWDP'
-H 'accept: application/json'

returns a bunch of non-JSON, but regularly formatted data.

[MikeNeilson]

I'll try to look into that by end of Monday. We did tweak how we're handling the Accept headers so that one probably just got mixed up.

[MikeNeilson]

Though if you don't mind trying to follow code, LevelsControllerTestIT might provide some insight into what should happen and how to call it.

[mdstanfill]

Can't make heads or tails of it.

Looks like it only sets level-id-mask as 'level_get_all.*', which doesn't look like a level mask at all to me. But I haven't ever done java test harnesses, so I don't really know what I'm looking at.

[MikeNeilson]

fair, some of the tests are better than others.
But the crash course is:

• anything with @test is actually a test, everything else is setup logic

• We use a library called "RestAssured" to organize the HTTP request workflow

  • the order is:
  • given(the parameters like level-id-mask=.* and headers),
  • when (the HTTP method and path e.g. Get /levels/,
  • then (this would be what we get)

• The actual response is rather hidden, but the tests should show the general request workflow, at least once you can make sense of the actual code.

But I'll look at that later, like I said might just be a hiccup from a fairly major change we made, hence "RC04" and not "here's the final release."

[MikeNeilson]

Okay, not a "bug" but definitely a slight design flaw. Try with:

curl -k -X 'GET' 'https://wm.nwp.ds.usace.army.mil:8243/nwdp-data-314rc3/levels?level-id-mask=CGR.%2A&office=NWDP&begin=1900-01-01T00%3A00%3A00%2B0000' -H 'accept: application/json;version=2'

In the swagger-ui set "begin" to 1900-01-01T00:00:00+0000

Apparently it defaults to previous 24 hours like the timeseries end point but that clearly doesn't make sense for location levels as sometimes there's only ever one for the life of the level.

[MikeNeilson]

I think turning that simple GET endpoint into a catalog the just returns the "levels matching mask + effective dates" it best, or adding a new catalog. But that should get you going for now anyways.