Re: Feature request - Optional API keys

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>
> *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.
>
>  
> <scripttype="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
>     <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 <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.
>
>          
>