Re: Feature request - Optional API keys

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>
Date: Tuesday, 23 July 2019 at 17:59
To: Antonin Delpeuch <antonin@delpeuch.eu>
Cc: "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<mailto: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<mailto:owen@ostephens.com>
Telephone: 0121 288 6936


On 22 Jul 2019, at 16:09, Alan Buxton <alan.buxton@opencorporates.com<mailto: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<https://opencorporates.com/>
Blog: http://blog.opencorporates.com<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.