Closed amyehodge closed 3 months ago
Maybe it would be helpful to see if this service is now available at a supported REST endpoint instead of talking directly to their Solr index?
https://www.oclc.org/developer/api/oclc-apis/fast-api/assign-fast.en.html
From OCLC FAST Team:
I believe our service is working okay but perhaps you are using an ‘experimental.worldcat.org’ url? We recently discontinued that avenue in favor of https://fast.oclc.org/searchfast/fastsuggest?&query=stuff. It should function the same, but if you run into any difficulties, please let us know.
Hope this helps, Russell
-- Russell Schelby OCLC, Technical Manager, Authorities schelbyr@oclc.org
@amyehodge We are using http://fast.oclc.org/fastIndex/select
https://fast.oclc.org/searchfast/fastsuggest?&query=stuff doesn't help because it doesn't include any identifiers.
@justinlittman I've sent another message to the FAST team about this.
From the docs it looks like you can request that idroot
be returned? Are those the identifiers that we have been using previously? The IDs look like fst01140419
. Here's an example API call:
@arcadiafalcone Can you answers @edsu 's question above about the identifiers? Thanks!
@edsu The identifiers used for what purpose? For the descriptive metadata, we're using the full URI, which can be derived from the idroot
, such as https://id.worldcat.org/fast/1140419/ for the above example, but I may be misunderstanding the question.
Thanks @arcadia. I'm just confirming that we could switch H2 over from using
http://fast.oclc.org/fastIndex/select
(which is now gone) to:
http://fast.oclc.org/searchfast/fastsuggest
As long as we request that it return identifiers (idroot
). We were initially concerned that the new service didn't seem to be returning identifiers.
Given that we had to wait for an H2 user to notice that this was broken I wonder if this is an opportunity to move the unit test over to querying the live service instead of mocking it out?
That should probably be an OKComputer check instead of a unit test.
I could understand OKComputer to make sure the URL still is 200 OK. But do we use OKComputer tests to ensure that the response format is still what we expect it to be?
@edsu @justinlittman Instead of hitting the live API in the test suite, or hammering it as part of OKComputer checks, how about we send Honeybadger alerts when the endpoint returns non-200 results? I'm going to work up a PR for that in the meantime.
worksforme
Currently this box in H2 behaves as a free text entry box. No type ahead search results appear when you type in the box.
App 176307 output: W, [2024-07-22T09:40:55.455746 #176307] WARN -- : [f24fa9fe-2590-42b5-ae17-5047e08d6a50] Autocomplete results for river returned 404