while that first Alaska library accessed through /rpc/lib_search_state or /rpc/lib_search_name has these, with a libid that contains an fscs sequence, where the Georgia library did not have a sequence:
libid sometimes contains fscs key only, and sometimes it contains key and sequence. It's different depending on which State your library is in, even with in the same API call.
fscs_id exists on one API call but not all three; where it is provided, it contains both fscs key and sequence. For some states, that means it duplicates libid.
Ideally, they'd respond with at least one reliable field in a consistent format, such as ZZ000-000, where ZZ is the state abbreviation followed by a library system id or "fscs key", then a hyphen, then the library branch id (often called fscs sequence).
Unfortunately, this format is not universally applied across states, library systems, and libraries. But we still need a unique key to show for each library, and it's hard to determine which of the many candidates is correct for this use. The key names and formats should at least be consistent between our own API calls, and if a UID is available in one call, it should be available in the others too.
library entries accessed through the following paths:
/rpc/lib_search_fscs
/rpc/lib_search_state
/rpc/lib_search_name
return results that have a lot of similar looking values for what we might use as an ID, but they are inconsistent:
An Alaska library, accessed through
/rpc/lib_search_fscs
, has these keys:While a Georgia library accessed through
/rpc/lib_search_fscs
has these keys:That same Georgia library accessed through
/rpc/lib_search_state
or/rpc/lib_search_name
contains these, missingfscs_id
:while that first Alaska library accessed through
/rpc/lib_search_state
or/rpc/lib_search_name
has these, with alibid
that contains an fscs sequence, where the Georgia library did not have a sequence:libid
sometimes contains fscs key only, and sometimes it contains key and sequence. It's different depending on which State your library is in, even with in the same API call.fscs_id
exists on one API call but not all three; where it is provided, it contains both fscs key and sequence. For some states, that means it duplicateslibid
.Ideally, they'd respond with at least one reliable field in a consistent format, such as ZZ000-000, where ZZ is the state abbreviation followed by a library system id or "fscs key", then a hyphen, then the library branch id (often called fscs sequence).
Unfortunately, this format is not universally applied across states, library systems, and libraries. But we still need a unique key to show for each library, and it's hard to determine which of the many candidates is correct for this use. The key names and formats should at least be consistent between our own API calls, and if a UID is available in one call, it should be available in the others too.