Hard coded API routes?

[weitzhandler]

Hi,

How am I supposed to query the FS database, using hardcoded API routes? Am I supposed to create a link generator? Why would I want to prefer this API over the old one?

[wooddani]

Using hard coded api routes allow less configuration issues and they do not change that often. Also, if someone must have a new route, then simply pulling the code down and changing the library is allowed. Going forward, I was explained that maintaining the older SDK was a challenge without many contributors. This lite SDK is a solution allowing less maintenance needed. It will not have as many breaking changes as Family Search API changes over time.

[weitzhandler]

It makes no sense having all the users create their own route mapper. Links are good for humans, not for computers or devs (super-human 😝 ).

Really bad news to hear that this is the direction of the new SDK. hard-coded links is a total no-go for me, and I believe for most .NET developers. Anyone who will use it will eventually end up creating their own mapper, which is a shame. There should at least be a separate class inheriting the SDK file and adding methods/properties encapsulating at least the common links.

And BTW, according to MS' naming guidlines, SDK in class names should be Sdk, so if this project is fresh enough, I'd change the class name to FamilySearchSdk.

[wooddani]

I too struggled with the hard coded urls, however have you ever tried pulling down a NuGet package and had to configure it when it was wrong? - Usually the package owner simply changes it which I'm not opposed to and welcome a pull request to set that up. I also followed the approach of the javascript lite sdk

[weitzhandler]

@wooddani You mean because the URLs are generated by the server, so we don't have to configure them? But you're not planning to display links to the user right? Even if it would be a web application (let alone if it's XAML), you would want to cover up the link with some text, so we need a system that generates link names. That's why I claim that we are going to need some mechanism that takes control of the links, be it with aid from the server, be it a static class with constant link names or other types of link builders, but leaving it hardcoded is a total nightmare for the long term. This is pretty tough for a stateless app. Needless to say for stateful apps such as a XAML based desktop/mobile app.

[wooddani]

I'm not following where you are going and an example would help. Additional api calls are already controlled within the code and simply toggling the environment changes the url. I wrote a web application already against the lite api and do need see the nightmare you are suggesting yet.

I think we are all also very open to code changes and happy to change direction as needed.

[weitzhandler]

I saw the examples but they all use hard-coded links. There has to be a wrapper for the repository class (the FamilySearchSDK class, that offers link generation, perhaps according to implied generic type and some other arguments.

[wooddani]

Are you implying the relative path examples of /platform/tree/persons/{pid} and /platform/tree/child-and-parents-relationships are the hard coded paths your concerned about?

[weitzhandler]

Yes, all of them. But maybe it's not such a big deal to make a static method class containing the routes after all.

[wooddani]

I personally would welcome such a solution if you have something in mind. A centralized static class of urls is typically how I have seen and coded those things in past. I understand your concern that hard coding a string in a method call seem wrong. The original intent of this C# Lite SDK, as I understand was to not include any such framework and let consumers make their own based on their needs.

[misbach]

@weitzhandler It's worth mentioning that you don't HAVE to hard code API endpoints using this SDK. You can use this SDK to initially call the Collections endpoints and then follow the links in the responses to get the data you want.