4 ms·

Sometimes its a preference of use. If the API is simple and easy to use, if it provides translations and transliterations you prefer, if it means not needing to

by asim 5y ago

Sometimes its a preference of use. If the API is simple and easy to use, if it provides translations and transliterations you prefer, if it means not needing to process xml or sql which I believe a lot of us would prefer not to do.

schoen 5y ago
Sure, at the cost of having something that usually has a higher latency for lookups, that only works online, that could have outages due to data center or network problems, that could get hacked and made to return corrupted data, and that may or may not be available forever. Those seem like pretty high costs to me mainly to avoid processing a local database. Especially if someone could wrap the local database with a library that has the same interface as the network API! (That library could stop being maintained, but the failure modes are much narrower than the failure modes of a network service.) A lot of the comments in this thread are suggesting that an API to search small public data is not a very productive approach compared to having that data present locally in programs that will use it. I can think of lots of advantages that network APIs could have: * querying nonpublic data (including nonpublic data that the end user is fully entitled to access all of, but doesn't want to cache on a mobile device because of its sensitivity) * applying a sophisticated algorithm to the data * offloading computation or storage to a more powerful device * dealing with frequent updates or edits to the data * ... However, none of those seem to apply readily to the case of searching a specific religious or literary text, because downloading the complete text is usually a very practical option. (I guess the "nonpublic data" part could also apply because some of the translations and transliterations and associated information might be under copyright, and the copyright holder might choose to authorize the API but not authorize bulk downloads of the database. That could also be true for modern commentaries and annotations.) The only other one that comes to mind for me in terms of people's enthusiasm for this API approach (and indeed in the comment I'm replying to) is * developers are very used to querying web APIs (and don't like writing their own parsers) That's fair, but I feel like it's best mitigated by having someone develop a reliable library for parsing a particular database or dataset, with a nice API that the developers will be happy with.

by asim 5y ago

schoen 5y ago

Sure, at the cost of having something that usually has a higher latency for lookups, that only works online, that could have outages due to data center or network problems, that could get hacked and made to return corrupted data, and that may or may not be available forever. Those seem like pretty high costs to me mainly to avoid processing a local database. Especially if someone could wrap the local database with a library that has the same interface as the network API! (That library could stop being maintained, but the failure modes are much narrower than the failure modes of a network service.) A lot of the comments in this thread are suggesting that an API to search small public data is not a very productive approach compared to having that data present locally in programs that will use it. I can think of lots of advantages that network APIs could have: * querying nonpublic data (including nonpublic data that the end user is fully entitled to access all of, but doesn't want to cache on a mobile device because of its sensitivity) * applying a sophisticated algorithm to the data * offloading computation or storage to a more powerful device * dealing with frequent updates or edits to the data * ... However, none of those seem to apply readily to the case of searching a specific religious or literary text, because downloading the complete text is usually a very practical option. (I guess the "nonpublic data" part could also apply because some of the translations and transliterations and associated information might be under copyright, and the copyright holder might choose to authorize the API but not authorize bulk downloads of the database. That could also be true for modern commentaries and annotations.) The only other one that comes to mind for me in terms of people's enthusiasm for this API approach (and indeed in the comment I'm replying to) is * developers are very used to querying web APIs (and don't like writing their own parsers) That's fair, but I feel like it's best mitigated by having someone develop a reliable library for parsing a particular database or dataset, with a nice API that the developers will be happy with.