API key inconsistency about public-apis HOT 14 CLOSED

@mikestreety beat me to it.... 👍

from public-apis.

Hi @bkazi - If an API key is required it should say so. If there are any missing this is just a mistake.

Now that we've merged a load, are there any you know require a key which isn't specified?

from public-apis.

May we add a column to check if an api key is required (when not using OAuth)?

See #189

from public-apis.

I think that issue has some validity - changing oAuth to Auth means the "No but an apiKey is required can be changed to just apiKey

from public-apis.

Current solution:

Rename-oauth-column solution:

Add-a-column solution:

I agree with @mikestreety, the second solution seems to be the neatest. What do think of it?

from public-apis.

Hmm, if we're to generate JSON from this data, then we want it to be as verbose as possible, right?

from public-apis.

I don't think we should let potential JSON-ification get in the way of readability? We could head down route two and then route three for the JSON and compile it into a route 2 looking table?

from public-apis.

Because this list of API's is publicly supported, I think the renaming the OAuth column to just Auth adds the opportunity to add a bit more detail into the method of authorization instead of just a blunt Yes/No. I would recommend this in hopes of keeping a consistent naming scheme so that we don't end up having variations of one type of Auth (apikey, ApiKey, Key, APIKEY, etc).

from public-apis.

We could add a "contributing" guide and include a list of existing ones so that several variations don't occur.

Are we looking to know that just an API Key is required? Is there any reason it's written apiKey? I assume that's the actual parameter name - but it seems to have malformed into a standard phrase

from public-apis.

To solve the issue of having multiple naming schemes for the same auth type, perhaps adding a table at the top of the README to explain the different choices for Auth would be best suited.

from public-apis.

There is one PR outstanding. Once merged I say let's go for this 👍

from public-apis.

I just opened a PR (#252) that adds a contributing guide to the project. I think it pretty much outlines what we are looking for in a submission (including the apiKey inconsistency), but if anyone has changes they'd like to propose, I'd be more than happy to add them in. :)

from public-apis.

This has also been resolved in the same PR 😄 Once merged we can finally get rid of this issue!

from public-apis.

Closing this as it is now resolved

from public-apis.