New Client interface
Closed this issue · 14 comments
This library should have a Client that can be instantiated with all of the configuration options needed to authenticate and begin utilizing the API. The Client should provide interface into making requests to the various modules of the /platform/ API, including the tree, memories, places, etc. It should utilize existing HATEOAS discovery and state transfers, but should provide a layer of abstraction that makes it easier to consume.
The gedcomx-java project has made a start at this:
Here is a proposal of what this might look like in PHP. Please provide feedback.
Looks good so long as we standardize on whether or not the options are using camel case.
I'm going to use camel case.
The namespacing in your example is FamilySearch\Client but that doesn't fit the current namespacing used in this package. Gedcomx\Extensions\FamilySearch\Rs\Client already exists as a namespace, not a class, so that might make things confusing. Perhaps Gedcomx\Extensions\FamilySearch\Client? Any other ideas?
This might not be as straightforward as we were hoping. StateFactory has the defaultClient() method which is where all client objects currently originate from. defaultClient() is a protected method.
Maybe the client could extend StateFactory.
I think Gedcomx\Extensions\FamilySearch\Client is fine.
I'm not following the defaultClient() comment. At what point do you need to access the defaultClient()?
Well I'm still figuring things out, but it appears that if a state is ever created without a Guzzle client then the defaultClient() method is called to create a Guzzle client with default options. If a user created this FamilySearch\Client and then some state was created that called defaultClient() they would lose the configuration specified in the FS client.
Did you follow that? Too many clients.
Following now. Let me take a deeper look.
StateFactory is in the Gedcomx\Rs\Client namespace but it contains some URIs to FamilySearch endpoints. It also has a flag for production which I don't think belongs there either. So my current line of thinking is to make StateFactory more generic and have the FamilySearch client extend it.
That will probably be a breaking change though.
We've decided to create a FamilySearchClient class in the Extensions\FamilySearch\Rs\Client namespace. It will use the FamilySearchStateFactory to create states. No breaking changes needed.
Would there be any advantage in have FamilySearchClient extend Gedcomx\Util\FilterableClient?
Something we didn't consider in our decision is that authentication is currently part of collection states via GedcomxApplicationState.