Api on Bruno Pedro

Bridging the Gap Between APIs and Customers

Mon, 03 Jun 2013 11:15:59 +0000

I recently gave a talk at the APIdays Mediterranea in Madrid where I started with a question: “Who are your customers?”.

The single, most important thing you want to understand about your API is how you can generate revenue from it. It all depends on who your customers are and how they can obtain value through your API.

What customers need is represented in one of the slides as the “API Hierarchy of Needs”, an adaptation of Maslow’s Hierarchy of Needs to the context of APIs from a customer point of view.

Still using HTTP Basic Auth?

Thu, 18 Apr 2013 15:22:17 +0000

Great article by Steve Graham about why you should stop using HTTP Basic Auth immediately!

As well as being tremendously simple, HTTP Basic by itself is also tremendously insecure, i.e. it is implemented by simply Base64 encoding the username and password concatenated with a colon “:” character. It then follows that HTTP Basic should only be used, if at all, over securely encrypted connections.

Original article: WHY THE HELL DOES YOUR API STILL USE HTTP BASIC AUTH?

Who’s using your API?

Mon, 11 Mar 2013 14:13:58 +0000

“Who’s using your API” was the title of my presentation at the API Strategy & Practice Conference that happened on February 21 and 22, 2013 in New York City.

One of the conference takeaways was the concern that almost everybody had with their customers. Almost everyone I talked with was in one way or another worried about how the API distribution model is affecting the way their customers interact with their app.

Writing great documentation

Tue, 27 Nov 2012 18:09:35 +0000

Writing great documentation

This advice will mostly be targeted towards those documenting libraries or frameworks intended for use by other developers, but much of it probably applies to any for of technical documentation.

To REST or not to REST

Mon, 20 Jul 2009 08:41:51 +0000

Yesterday @esjewett pointed out that tarpipe’s API 2.0 might not be considered RESTful. Quoting the previously written article “A RESTful ESME API”:

REST is often seen as an alternative to RPC APIs, or “Remote Procedure Call” APIs. At root, the difference as described by Wikipedia is that RPC is about telling an application to do something while REST is about changing the state of the resources of an application.

Paul Sadauskas, on another article about the same subject, adds some rules that your API should not follow:

Clients have to read documentation to know the locations of top-level resources.

Clients have to concatenate strings to get to the next resource.

You have an “API/Key/Token” in a header or a url.

You have a version string in a url.

All this made me think about possible changes to become RESTful. Things seem to be easy when you’re offering operations to resources you own or control. When you’re dealing with processes that’s a whole different story. As @esjewett best puts it:

Should twitter have its own data storage?

Tue, 21 Apr 2009 12:34:56 +0000

Now that twitter OAuth feature is in public beta, some people argue that twitter should also provide a data storage facility through their API. This would allow developers to add payloads to different twitter objects but would create another information silo, instead of leveraging existing data storage providers.

I agree with Kevin Marks when he asks “Why should the storage and the event stream come from the same provider?”.

Quoting Dave Winer’s article “Twitter and OAuth, interesting brew”: