- From: Antonin Delpeuch <antonin@delpeuch.eu>
- Date: Wed, 6 Nov 2019 14:09:22 +0000
- To: public-reconciliation@w3.org
- Message-ID: <9490f352-ef29-cc0a-7432-f6d926cd7031@delpeuch.eu>
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>
>> *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).
>> Seehttps://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.
>>
Received on Wednesday, 6 November 2019 14:09:33 UTC