- From: Thad Guidry <thadguidry@gmail.com>
- Date: Tue, 23 Jul 2019 11:58:47 -0500
- To: Antonin Delpeuch <antonin@delpeuch.eu>
- Cc: public-reconciliation@w3.org
- Message-ID: <CAChbWaNAc=2xhBy7qNMBQy9M4vvPwKX+P8G1EW3k6+_H__Aa=g@mail.gmail.com>
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. > > >
Received on Tuesday, 23 July 2019 16:59:24 UTC