Prior to this commit, we used different initialization logic for linked
data authorities and non-linked data. Further, the initialization logic
was locked away inside of a controller.
With this commit, we expose a method that provides consistent
initialization logic; albeit with different returned classes that have
slightly different implementation nuances. The application can then
rely on that and we can share initialization logic across controllers
and also expose a method that allows non-controller initialization to
begin to follow the same logic pathway.
Where are the tests? The initializations are covered by controller
tests, so I have chosen not to write new ones.
There is further work to do because LinkedData and non-LinkedData there
are different signatures for find and search. Ideally, we would
normalize the public facing implementation logic. However, this commit
preserves backwards compatibility, simply introducing a new feature.
Introducing Qa::AuthorityWrapper
baf399f2dba6c45c99f90483242dc047ff94e47b
Prior to this commit, the returned value from Qa.authority_for was
something that was inconsistent. Depending on the controller (or authority), the find
and search would require different parameters.
With this commit, those nuances are encapsulated in their own methods.
This begins to work towards a more foundational promise of questioning
authority; namely that the end point that asked questions of QA didn't
need to know which type of authority it was.
That promise was partially delivered at the routes level but this commit
pushes that down to the internal API level.
As a bonus, and perhaps confusion, I've included the
Qa::AuthorityRequestContext as an interface to help convey how one
might provide a different (non-controller) context to instantiating and
authority.
WIP Reworking authority request context
4fd490729e5b0c9a17f7686a3ad4c773fb879f33
require context and update logic of fetch/search header methods
d3c51a573f7d96f2cddb01a1c2379373b8559482
Adding a Qa::Authorities::Loc.type_for
79a13f959e00b08c32557dbe7484c0912f4b9908
Prior to this commit, we always assumed that each "find" would request
from https://id.loc.gov/authorities.
With this commit, we use the "subauthority" to inform what the base URL
is for the https://id.loc.gov/ host. In some cases this is
authorities and in others it's as the code indicates.
Extracting
Qa.authority_for24776bc3a47d6211383874f06544ba5a9225ede9
Prior to this commit, we used different initialization logic for linked data authorities and non-linked data. Further, the initialization logic was locked away inside of a controller.
With this commit, we expose a method that provides consistent initialization logic; albeit with different returned classes that have slightly different implementation nuances. The application can then rely on that and we can share initialization logic across controllers and also expose a method that allows non-controller initialization to begin to follow the same logic pathway.
Where are the tests? The initializations are covered by controller tests, so I have chosen not to write new ones.
There is further work to do because LinkedData and non-LinkedData there are different signatures for
findandsearch. Ideally, we would normalize the public facing implementation logic. However, this commit preserves backwards compatibility, simply introducing a new feature.Introducing
Qa::AuthorityWrapperbaf399f2dba6c45c99f90483242dc047ff94e47b
Prior to this commit, the returned value from
Qa.authority_forwas something that was inconsistent. Depending on the controller (or authority), thefindandsearchwould require different parameters.With this commit, those nuances are encapsulated in their own methods. This begins to work towards a more foundational promise of questioning authority; namely that the end point that asked questions of QA didn't need to know which type of authority it was.
That promise was partially delivered at the routes level but this commit pushes that down to the internal API level.
As a bonus, and perhaps confusion, I've included the
Qa::AuthorityRequestContextas an interface to help convey how one might provide a different (non-controller) context to instantiating and authority.WIP Reworking authority request context
4fd490729e5b0c9a17f7686a3ad4c773fb879f33
require context and update logic of fetch/search header methods
d3c51a573f7d96f2cddb01a1c2379373b8559482
Adding a
Qa::Authorities::Loc.type_for79a13f959e00b08c32557dbe7484c0912f4b9908
Prior to this commit, we always assumed that each "find" would request from
https://id.loc.gov/authorities.With this commit, we use the "subauthority" to inform what the base URL is for the
https://id.loc.gov/host. In some cases this isauthoritiesand in others it's as the code indicates.Hopefully works to close the following: