Re: Feature request - Optional API keys

Makes perfect sense, Antonin.  I think those 3 levels are fine.
A register/signup link is also a good idea.
+1

Thad
https://www.linkedin.com/in/thadguidry/


On Wed, Nov 6, 2019 at 8:09 AM Antonin Delpeuch <antonin@delpeuch.eu> wrote:

> Hi all,
>
> I thought about this a bit more, and my intuition is that it would be good
> to specify how services can announce that they support or require an API
> key.
>
> I imagine we could add that in the manifest somewhere. That would make it
> possible for UIs to prompt the user for an API key when applicable.
>
> I can imagine multiple use cases:
>
> - endpoints which always require an API key
>
> - endpoints where an API key unlocks particular features (some particular
> properties or types which cannot be used by default, for instance)
>
> - endpoints where supplying an API speeds up the reconciliation
>
> So perhaps we could have three levels: not required, optional and required?
>
> There are other things we could consider adding, such as a user-friendly
> name for the API key with the terminology that the service uses in other
> contexts ("token", "password", …) which could be displayed to the user when
> prompting for the API key (so that they understand better what to enter).
> And/or a link to a page which explains how to get a token, for instance.
>
> What do you think about that?
>
> Antonin
> On 25/09/2019 08:57, Antonin Delpeuch wrote:
>
> I found this old thread where the feature was discussed more extensively:
>
>
> https://groups.google.com/forum/#!searchin/openrefine/reconciliation$20API|sort:date/openrefine/hbhT7CFy5PE/PxApScXQL0gJ
>
> So it looks like a GET parameter is indeed the preferred way to go, with
> "api_key" as parameter name.
>
> Antonin
> On 24/07/2019 10:25, Alan Buxton wrote:
>
> Great that we are all on the same page.
>
>
>
> My  vote would be similar to what you outline below, but just to call the
> parameter “api_token” to make it crystal clear what it is to anyone who is
> looking at the URL.
>
>
>
> *From: *Thad Guidry <thadguidry@gmail.com> <thadguidry@gmail.com>
> *Date: *Tuesday, 23 July 2019 at 17:59
> *To: *Antonin Delpeuch <antonin@delpeuch.eu> <antonin@delpeuch.eu>
> *Cc: *"public-reconciliation@w3.org" <public-reconciliation@w3.org>
> <public-reconciliation@w3.org> <public-reconciliation@w3.org>
> *Subject: *Re: Feature request - Optional API keys
>
>
>
> Please for the love of OpenRefine...
>
>
>
> Let's do it like the big boys do and use an authorization token (a
> parameter).  Debugging bad requests are easier on the consumer.
>
> Bolting it together for the publisher of the service is trivial and
> marginally better than headers. And easier for them to debug as well!
>
>
>
> For those publishers that later want to enable Oauth dancing, it will be
> easier to support that upgrade path.
>
>
>
> <script type="text/javascript" src="https://maps.googleapis.com/maps/api/js?key=*YOUR_API_KEY*&*libraries=places*"></script>
>
>
>
> Thad
>
> https://www.linkedin.com/in/thadguidry/
>
>
>
>
>
> On Tue, Jul 23, 2019 at 9:01 AM Antonin Delpeuch <antonin@delpeuch.eu>
> wrote:
>
> Thank you Alan for chiming in!
>
> I agree with you and Owen that it would be a useful thing to support. I do
> believe this should be specified as part of the API, so that it can be
> supported in a uniform way. Let us keep this on our list of things to add
> to the specifications.
>
> The corresponding OpenRefine issue is here:
>
> https://github.com/OpenRefine/OpenRefine/issues/2015
>
> A pull request for this has been submitted in the past:
> https://github.com/OpenRefine/OpenRefine/pull/758
>
> Antonin
>
> On 7/23/19 8:29 AM, Owen Stephens wrote:
>
> As a member of the OpenRefine community and a contributor to the
> development, I would say that we should support API keys
>
>
>
> From the perspective of this group I guess the wider question is whether
> we should have a standardised way of supporting API keys for reconciliation
> services - should this become part of the API? Should it just be an
> optional request Header? Or just something added to the URL?
>
>
>
> Owen
>
>
>
> Owen Stephens
>
> Owen Stephens Consulting
>
> Web: http://www.ostephens.com
> Email: owen@ostephens.com <owen@ostephens.com>
> Telephone: 0121 288 6936
>
>
>
> On 22 Jul 2019, at 16:09, Alan Buxton <alan.buxton@opencorporates.com>
> wrote:
>
>
>
> Hi all
>
>
>
> I’m writing from OpenCorporates who provide a reconciliation service
> (among other API services). See
> https://reconciliation-api.github.io/testbench/.
>
>
>
> We provide all our APIs under either an entirely open basis or via an API
> key. We issue API keys free of charge for public benefit users, and on a
> paid basis for corporate users. We have 3 types of users: users who use our
> services without an API key, public benefit users (e.g. journalists) who
> use our services with a free API key and those who use our services with a
> paid API key.
>
>
>
> OpenRefine does not currently support API keys, so OpenRefine users are
> only able to use our API through the public endpoint. To improve
> performance, make our service more maintainable and generally manage it
> better, we are going to be retiring some of the underlying functionality in
> our main app that supports use without API key. But we want to make sure we
> can still provide this service to public benefit users, so we need to be
> able to support (optional) API keys.
>
>
>
> What is the view in the community about OpenRefine providing support for
> (optional) API keys?
>
>
>
> Alan Buxton
> CTO
>
> --
>
> OpenCorporates :: The Open Database of the Corporate World
> https://opencorporates.com
> Blog: http://blog.opencorporates.com
> Twitter: http://twitter.com/OpenCorporates
> OpenCorporates Ltd is a company dedicated to improving and publishing
> public data under an open licence that allows and encourages reuse,
> including commercially. Registered in England, number 07444723.
>
>
>
>