Comments on: API Hierarchy of Needs

By: Applying Psychology to APIs: the Best of API Hierarchies of Needs

Applying Psychology to APIs: the Best of API Hierarchies of Needs — Fri, 31 Jul 2015 13:52:38 +0000

[…] Read the article here. […]

By: API Hierarchy of Needs | Software Development |...

API Hierarchy of Needs | Software Development |... — Sat, 22 Mar 2014 01:05:05 +0000

[…] “ The hierarchy of needs is a pyramid divided into five different layers that represent different characteristics that you should consider when launching and maintaining an API.” […]

By: API Hierarchy of Needs | API Magazine: About AP...

API Hierarchy of Needs | API Magazine: About AP... — Fri, 21 Mar 2014 14:49:36 +0000

[…] The hierarchy of needs is a pyramid divided into five different layers that represent different characteristics that you should consider when launching and maintaining an API. […]

By: Bruno Pedro

Bruno Pedro — Wed, 31 Jul 2013 16:01:52 +0000

In reply to Peter Verhas.

I wouldn’t worry so much about the possibility of breaking backward compatibility. If things are done the right way, you should offer API versioning (/2013/05/14/api-versioning/), meaning that there’s no way to break things.

I agree with your way of looking at the API with a dynamic view — thanks for sharing it.

By: Peter Verhas

Peter Verhas — Tue, 30 Jul 2013 14:22:29 +0000

“Can it be used in unexpected ways?” That really would worry me. Your argument is absolutely valid on one hand. The more versatile, open and applicable the API is the more attractive it is for the developers/users. On the other hand if you open up your application giving access to all internal features you did not even have ideas how could be used, you may end up with an application that you can not develop without breaking backward compatibility.

API should be designed with the open/close principle in mind. You model is static, looking at the values the API can deliver for a certain version. Looking at the API with a dynamic view is more important: what value can your API deliver during the life time of the domain and you application supporting that domain.

By: Scott Reed

Scott Reed — Thu, 06 Jun 2013 17:16:30 +0000

In reply to Bruno Pedro. And conversely if your API has broken features or has bad uptime it doesn't really matter how usable it is. A pyramid model which places one of several important needs over others might not be the best idea. A better model would be one which places equal importance on needs such as usability, functionality and reliability.

By: Bruno Pedro

Bruno Pedro — Thu, 06 Jun 2013 08:12:28 +0000

In reply to Scott Reed. Placing Usability at the bottom of the pyramid is generating an interesting debate among several people. If your goal is to make your API successful, you need to be able to evangelize developers into using it. If developers cannot even use it, it really doesn't matter if your API works at all, does it?

By: Scott Reed

Scott Reed — Wed, 05 Jun 2013 17:28:30 +0000

I disagree with placing usability above functionality and reliability in importance. An API actually working is much more important to me. For example, the Twilio API has great usability but the biggest frustration I’ve had with it is when features did not work. With the AWS API, the error codes it gives are pretty much useless.

By: Bridging the Gap Between APIs and Customers | Bruno Pedro

Bridging the Gap Between APIs and Customers | Bruno Pedro — Mon, 03 Jun 2013 11:19:02 +0000

[…] 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 […]

By: Bruno Pedro

Bruno Pedro — Mon, 03 Jun 2013 09:21:45 +0000

In reply to API Rating Agency (@API500). Thanks for sharing the link, so we can all see different perspectives! The pyramid I presented at APIdays was not this one. It was an adaptation of this one but from a customer (not a developer) point of view.