Show HN: Dog API (dogapi.dog)

I wanted to build this as an API. What are the advantages - learning wise - of using a file with the relevant information?

I've tried to curate the information as good as possible, but some facts are hard to confirm. Same for breed descriptions and other data.

The main goal is to expose a fun API, and then be as accurate as possible. I'm working on the latter.

Thank you for pointing that out, I've updated the Swagger file to make it work as expected.

Thank you! Feel free to contribute to the main repository [1], using "buy me a coffee" in the FAQ, or GH Sponsors program [2] to support the server.

[1]: https://github.com/kinduff/dogapi.dog#contributing

[2]: https://github.com/sponsors/kinduff

It would be awesome to see that list you have!

You might also like:

https://randomuser.me/api/

Will give it a thought, thanks for your comment.

This is what I was hoping for - and of course there would be a cat option but it would simply return “not implemented” for everything.

402 Treats Required

I was expecting it to be dog slow.

Expectations. I was expecting an API for dogs to use. Bark once for a treat, put paw on human for some affection, scratch at the door to go out, etc.

Unrelated to OP, but is it SOP for Russian agencies to deliberately obfuscate or outright lie on otherwise uncontroversial data?

> Laika died within hours from overheating, possibly caused by a failure of the central R‑7 sustainer to separate from the payload. The true cause and time of her death were not made public until 2002; instead, it was widely reported that she died when her oxygen ran out on day six or, as the Soviet government initially claimed, she was euthanised prior to oxygen depletion.

There seems to be little reason to lie about this given Laika's survival was already nil.

Files/dumps as an API is vastly underrated.

Considering a set of relatively infrequently changing facts about external world, publishing them as RDF can be a good choice. Developers can use it in whatever way they need, including loading it into SQLite—and it’s self-documenting, so they don’t need some extra information such as a spec to explain what everything means. It can link to external data for things beyond its scope that someone else already took care of. Other data can link to it, too—so it benefits open information exchange.

(Yes, RDF has got a bit of a bad rap in some circles, but I don’t think it’s entirely justified… More importantly, RDF is incredibly boring, so publishing such a dataset is likely to gather much less attention than releasing a free public API, at least here.)

For this use case that works well but a big part of that learning is the data is fairly static and likely doesn’t update often

I agree, but also don't underestimate the problems and risks in real systems that keep changing.

I've shipped some data in a JSON file bundled with an application, because it didn't change a lot, and we had frequent (biweekly) releases anyway. I mistakenly assumed those two things would always be true.

As time went on, the frequency of necessary changes increased but our overall products release cadence got worse and worse (many months) as the product grew. So customers had continually outdated data.

An additional problem I didn't expect is that since we wanted to get customers the latest data (because the next release was so far out), we had to update the data set as close to release as possible. So always a change at the last minute, which is already a busy time and means it's not really tested well. And also it was extra toil; we had a script for data generation but it still needed a manual run and pull request. In the time I spent running this I could have easily written an API based version several times.

Another problem was that this change had to be made for every release, including bugfix ones. This caused frequent discussion (do we need this?), was forgotten a few times, and caused merge conflicts later which were annoying because in this case the proper way to merge was to ignore both ancestors and rerun the script, which people weren't used to.

Of course I rewrote it eventually (after convincing PM that I need time for this supposedly long done feature again), but then I had to deal with the extra problem of customers who had local customer specific modifications of the file (because that was the workaround our support staff came up with as a way to deal with the outdatedness).

Thankfully, a problem I did not habe was binary data in git. The commits were ugly but at least still got ok diffs (once we sorted the JSON file properly). But you mentioned SQLite, which is not a good match for git. Of course one can work around it by merging the raw SQL, but still, yet another pitfall.

More FE-relevant, but also relevant: https://placekitten.com/

I'm gathering some images for breeds, already have everything in place to upload them. This feature will come soon.

I love the fact that Cat API offers an Enterprise plan.

> With V2, I'm planning to add new features including breeds, pictures, and other cool dog data.

There was a dog api that sent dog images, it was a few years ago that I last saw it in action though.

“Cat as a Service” is my go to for these kinds of things.

https://cataas.com/#

That is correct, it is referring to that standard.

Really like the documentation, will try something similar, additionally to the Swagger UI.

Take a look at the JSON:API specification https://jsonapi.org

"Before you speak ask yourself if what you are going to say is true, is kind, is necessary, is helpful. If the answer is no, maybe what you are about to say should be left unsaid."

I suppose the style sheet for the site could be named dog-style.css?

Wait - maybe not a good name after all.

I thought Slack was just a way to share screen Is it a platform for apps ?

Long story short: I built the app under my ex-employer Slack, and apps are tied to organizations. When I was removed from the organization, I lost access to the app. Couldn't recover it, I've been trying for years.

> On June 20, 2011, ICANN's board voted to end most restrictions on the creation of generic top-level domain names (gTLDs) -- at which time 22 gTLDs were available. Companies and organizations would be able to choose essentially arbitrary top-level Internet domains.

> The initial price to apply for a new gTLD was $185,000. ICANN expected the new rules to significantly change the face of the internet. Industry analysts predicted 500–1000 new gTLDs, mostly reflecting names of companies and products, but also cities, and generic names like bank and sport.

> ..Esther Dyson, the founding chairwoman of ICANN, wrote that the expansion "will create jobs [for lawyers, marketers and others] but little extra value."

https://en.wikipedia.org/wiki/Generic_top-level_domain#New_t...

You seem to be describing something like a classic P2P content-distribution system - BitTorrent w/ magnet links, IPFS, CoralCDN, etc. Could you explain a bit more what part of your proposal would be incompatible with those existing systems?

The blockchain does not need to be thrown at every source of data store.

Sometimes a tiny lil' db is all you need to serve some nice cacheable data :)