On Sun, Dec 1, 2013 at 7:57 PM, Barnes, Hugh hugh.bar...@lincoln.ac.nzwrote:
+1 to all of Richard's points here. Making something easier for you to
develop is no justification for making it harder to consume or deviating
from well supported standards.
I just want to point out that as much
Hi Richard,
On Sun, Dec 1, 2013 at 4:25 PM, Richard Wallis
richard.wal...@dataliberate.com wrote:
It's harder to implement Content Negotiation than your own API, because
you
get to define your own API whereas you have to follow someone else's rules
Don't wish your implementation problems on
On Sun, Dec 1, 2013 at 5:57 PM, Barnes, Hugh hugh.bar...@lincoln.ac.nzwrote:
+1 to all of Richard's points here. Making something easier for you to
develop is no justification for making it harder to consume or deviating
from well supported standards.
I'm not suggesting deviating from well
On 12/2/13 10:50 AM, Robert Sanderson wrote:
On Sun, Dec 1, 2013 at 4:25 PM, Richard Wallis
richard.wal...@dataliberate.com wrote:
As to discovering then using the (currently implemented) URI returned from
a content-negotiated call - The standard http libraries take care of that,
like any
Yeah, I'm going to disagree a bit with the original post in this thread,
and with Richard's contribution too. Or at least qualify it.
My experience is that folks trying to be pure and avoid an API do _not_
make it easier for me to consume as a developer writing clients. It's
just not true
Though I have some quibbles with Seth's post, I think it's worth
drawing attention to his repeatedly calling out API keys as a very
significant barrier to use, or at least entry. Most of the posts here
have given little attention to the issue API keys present. I can say
that I have quite
I'm not going to defend API keys, but not all APIs are open or free. You
need to have *some* way to track usage.
There may be alternative ways to implement that, but you can't just hand
wave away the rather large use case for API keys.
-Ross.
On Mon, Dec 2, 2013 at 12:15 PM, Kevin Ford
There are plenty of non-free API's, that need some kind of access
control. A different side discussion is what forms of access control are
the least barrier to developers while still being secure (a lot of
services mess this up in both directions!).
However, there are also some free API's
I think the best compromise is what Google ends up doing with many of
their APIs. Allow access without an API key, but with a fairly minimal
number of accesses-per-time-period allowed (couple hundred a day, is
what I think google often does).
-- Agreed.
I certainly didn't mean to suggest
To be (more) controversial...
If it's okay to require headers, why can't API keys go in a header rather
than the URL.
Then it's just the same as content negotiation, it seems to me. You send a
header and get a different response from the same URI.
Rob
On Mon, Dec 2, 2013 at 10:57 AM, Edward
I do frequently see API keys in header, it is a frequent pattern.
Anything that requires things in the header, in my experience makes the
API more 'expensive' to develop against. I'm not sure it is okay to
require headers.
Which is why I suggested allowing format specification in the URL,
Amazon Web Services (which is probably the most heavily used API on the Web)
use HTTP headers for authentication. But I guess developers typically use
software libraries to access AWS rather than making the HTTP calls directly.
//Ed
A key (haha) thing that keys also provide is an opportunity
to have a conversation with the user of your api: who are they,
how could you get in touch with them, what are they doing with
the API, what would they like to do with the API, what doesn’t
work? These questions are difficult to ask
umm... it's called HTTP-AUTH, and if you really want to be cool, use an
X.509 client cert for authorization (see geoserver as an example that
works very cleanly -
http://docs.geoserver.org/latest/en/user/security/tutorials/cert/index.html;
the freebxml registry-repository also uses X.509 based
On Dec 2, 2013, at 1:25 PM, Kevin Ford wrote:
A key (haha) thing that keys also provide is an opportunity
to have a conversation with the user of your api: who are they,
how could you get in touch with them, what are they doing with
the API, what would they like to do with the API, what
] On Behalf Of Edward
Summers
Sent: Tuesday, 3 December 2013 6:57 a.m.
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] The lie of the API
On Dec 3, 2013, at 4:18 AM, Ross Singer rossfsin...@gmail.com wrote:
I'm not going to defend API keys, but not all APIs are open or free.
You need to have
I'm confused about the supposed distinction between content negotiation and
explicit content request in a URL. The reason I'm confused is that the
response to content negotiation is supposed to be a content location header
with a URL that is guaranteed to return the negotiated content. In
It's harder to implement Content Negotiation than your own API, because you
get to define your own API whereas you have to follow someone else's rules
Don't wish your implementation problems on the consumers of your data.
There are [you would hope] far more of them than of you ;-)
On Dec 1, 2013, at 3:51 PM, LeVan,Ralph wrote:
I'm confused about the supposed distinction between content negotiation and
explicit content request in a URL. The reason I'm confused is that the
response to content negotiation is supposed to be a content location header
with a URL that is
.
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] The lie of the API
It's harder to implement Content Negotiation than your own API, because you
get to define your own API whereas you have to follow someone else's rules
Don't wish your implementation problems on the consumers of your data
Returning a content location header does not require a redirect. You can
return the negotiated content with the first response than still tell the
client how it could have asked for that same content without negotiation.
That's what the content location header means in the absence of a
On Dec 1, 2013, at 7:57 PM, Barnes, Hugh wrote:
+1 to all of Richard's points here. Making something easier for you to
develop is no justification for making it harder to consume or deviating from
well supported standards.
[Robert]
You can't
just put a file in the file system, unlike
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Joe
Hourcle
(They are on Wikipedia so they must be real.)
Wikipedia was the first place you looked? Not IETF or W3C?
No wonder people say libraries are doomed, if even people who work in
On Dec 1, 2013, at 9:36 PM, Barnes, Hugh wrote:
-Original Message-
From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Joe
Hourcle
(They are on Wikipedia so they must be real.)
Wikipedia was the first place you looked? Not IETF or W3C?
No wonder people say
On Dec 1, 2013 6:42 PM, Joe Hourcle onei...@grace.nascom.nasa.gov wrote:
So that you don't screw up web proxies, you have to specify the 'Vary'
header to tell which parameters you consider significant so that it knows
what is or isn't cacheable.
I believe that if a Vary isn't specified, and the
On Dec 1, 2013, at 11:12 PM, Simon Spero wrote:
On Dec 1, 2013 6:42 PM, Joe Hourcle onei...@grace.nascom.nasa.gov wrote:
So that you don't screw up web proxies, you have to specify the 'Vary'
header to tell which parameters you consider significant so that it knows
what is or isn't
(posted in the comments on the blog and reposted here for further
discussion, if interest)
While I couldn't agree more with the post's starting point -- URIs identify
(concepts) and use HTTP as your API -- I couldn't disagree more with the
use content negotiation conclusion.
I'm with Dan Cohen
Hi,
I was happy to read this blog post, because it contain lots of very
important statements, but as one of the developers of Europeana API I
would like to mention some points.
The idea of content negotiation is nice, but it also adds some
additional burden for the API users. In some tools and
Seth (and commenters) -
The basic point is sound, but there are some important issues that are
averted or are elided in the original article in order to make the
underlying point more clearly.
1: It should be quite clear that there is no need to develop an API for
the sole purpose of
29 matches
Mail list logo
