
Why you absolutely MUST write an API when you write your next app - toast76
http://blog.angrymonkeys.com.au/why-you-absolutely-must-write-an-api-before-y
======
JoelSutherland
Don't build an app, build an API, then build an app.

This is what we did with our product, a CMS (<http://www.gethifi.com>). We
built a very flexible API that has cool things like permissions, relationships
and versioning built in. Then we built our app and interface on top of that.

This turned out to have tons of advantages. Our app development went very
quickly. It was much easier to do testing. Improvements to the API are now
universally available.

On top of all of that, there is an awesome API available for every site on the
system!

By inverting the way you think about the API, (build on the API, vs. build an
API for an app) you end up with an API that is much more polished as well.

~~~
mncaudill
First off, hey Joel!

We do the exact same thing at Flickr. Anytime the front-end needs an method to
do something, we'll build it in (though it may not always make its way into
our public API).

The nice thing is if we change the behavior of an API method inadvertently, we
catch it instantly since the site itself reveals the bugs.

~~~
JoelSutherland
Wow -- hey Nolan!

We have the same experience (at a much smaller scale!). We can pull down
production sites into a VM to see what happens whenever we make an API
improvement. It is a great way to catch subtler things too like performance
changes.

------
rue
I wish the startupentrepreneurhackerpainter-scene used more precise terms.
This kind of titling makes it all seem so damned naïve.

An API, application programming interface, is an interface presented by some
means into some kind of an application, possibly itself. A C library, for
example, presents an API. Both external (public) and internal (private) APIs
may exist, as well as intermediate forms.

An app, application, is a software program.

Here the advice is of a unified (public + private) web-based presumably
RESTish API into a web application right from the start.

Contrary to the author's experience (or nomenclature), it seems to me that
engineers typically do ensure their application has an API.

~~~
wlievens
I can second your question. When you build an app with a dynamic frontent
(i.e. javascript) and a "database" (I don't care what model) driven backend,
then you need a way to pass data and commands (e.g. JSON) between the two.

Thus you end up with pages that handle requests and return data in a
structured presentation-agnostic fashion. Isn't that already an API?

------
sbov
Much of what I read about this talks about, e.g., building a REST API then
using that in your application rather than direct database access.

Isn't this largely "Program to an interface, not an implementation" wrapped up
in webspeak?

Whenever we start a new web project, we organize our code into groups of
services, and use interfaces to represent those groups rather than concrete
classes. Where possible, the implementation of the interfaces are direct
database calls. When we need to use it externally, we have an implementation
that uses remote calls.

So ultimately we program to interfaces which are designed to be automatically
exposed as an API call. In some ways the recommendation to rely on your own
REST API to build out your application feels like a way to make up for the
lack of structure interfaces can enforce. Maybe I'm wrong though.

------
Nate75Sanders
This is essentially bottom-up programming where you build a small language
first (could be just functions, not a "real" new language), then build your
app out of your new language. Paul Graham advocates/advocated this.

Being able to figure out what primitive pieces are important now and will be
important later is something that takes practice and something that I've never
ever been able to convince a manager of the importance of and that it's far
more important than knowing 25 design patterns or some similar buzzwordy
stuff. There are many ways to decompose problems. Bottom-up is the right way,
though. Contrast with top-down/stepwise refinement for the wrong way.

------
byoung2
This was a very apropos read for me, since I'm working on my next app by
starting with the API. I have been working with quite a few API's and I've
found that a lot of them felt like their creators never used them. So I'm
building an API that I would use myself, and I'm forcing myself to live up to
that promise by building the rest of the app on top of the API. I'll let you
guys know how that goes!

~~~
hsmyers
The best way to create an API that feels like their creators never used them
is to build one that you would use yourself. If you want to build one that
others can use and use easily then you need to put yourself in their shoes,
not your own. Otherwise it's just one more library built on some one else's
idea of a good time. That said if absolutely no one else is ever going to see,
let alone use this API, then certainly build what works for you... just
remember the maxim of writing as though the person/maintainer after you is a
psychopath who knows where you live.

~~~
jamii
Or even better, write the app's frontend using the public API (and only the
public API, no cheating).

------
cletus
I'm a little more cautious about this and would suggest three caveats:

1\. Building an API from day one can be premature. Typically when you start
building something is the time when you know the least about the problem
you're trying to solve and the issues you'll face solving it. That problem is
subject to much more change early than late. If you build an API on day one
may just be creating more work for yourself later on;

2\. If you provide a public API, you are quite possibly exposing your data
model and any assumptions that underpin it. This can make it much harder to
change later as circumstances change. Think of it as making everything
(including data members) public in class. It's abstraction; and

3\. What value does an API provide _you_ as the service provider?

Twitter is an easy example of this: it doesn't really matter where the Tweets
(sorry nytimes) come from as Twitter owns the graph, the distribution and the
Tweets.

Now consider a site like Stackoverflow. What if you could ask questions,
search for answers, vote, view your summary information and so on completely
via an API. What value would there be in the SO site? Not much at all and it's
the ads on those pages that pay for the site (well that and $x million from
USV).

------
dannyr
The new Twitter.com is using its own API.

[http://engineering.twitter.com/2010/09/tech-behind-new-
twitt...](http://engineering.twitter.com/2010/09/tech-behind-new-
twittercom.html)

------
atldev
This applies to enterprise software as well. I was an architect for a large
CRM project with Siebel and software from a company called Yantra (acquired by
SterlingCommerce). The difference between the two? Siebel "bolted on" an API
layer and Yantra consumed their own API for internal, core functions.

The difference was night and day. As expected, the Siebel API was practically
useless. Yantra's was rock-solid. No better way to make sure your API is solid
than to use it internally.

------
pig
A big part of engineering is about making the right trade-offs at any given
point. His straw-man engineer shows nothing but his misunderstanding of
engineering.

~~~
mmilo
I think the engineer in his example wasn't meant to be an accurate portrayal,
but rather serve to emphasize that his approach is more haphazard.

------
jallmann
Good thoughts. The article did not say this outright, but it is also nice to
build a chunk your app (if not all of it) on top of your own API. Not only is
this good housekeeping, it helps in decoupling your code and forces you to
keep things in bite-sized, maintainable, testable pieces.

------
ThomPete
I call this WMC (Weapons of Mass Connection)

Edit: Don't know why I got downvoted but I guess the above statement needs
some context: <http://000fff.org/the-power-of-digital-ecoystems/>

------
perssontm
What would you choose to use as a api, something json-based or soap or what?
Which is the easiest for the users/other developers to implement?

