API First, Mobile Second, Web Third | Hacker News Reader

API First, Mobile Second, Web Third

switzer.org

24 pointsbjonathan17 comments

Solve a problem someone has first. Rarely will that solution be an API. Advice is never universally right or universally wrong, but the advice in this post is almost universally wrong.

In some part I agree with you., but that's now. In the near future more and more services and apps will have an API as a primary way to be accessed by third party developers.

Don't know if that will be your need since all depend from the service itself if it is useful or not. But we have to bear in mind that Twitter has 75% of its traffic coming from its APIs, while eBay has 8 billion of worth items pushed through the marketplace via APIs. That's the future, especially when the internet of things will come, at that point your toaster will have an API as well.

Twitter and eBay both had significant web presence and community before their APIs took off. So did Facebook. Only once you have something worth getting at will people want to integrate with you.

To be fair, a lot of Twitter's success was due to their API, but without a decent minimal web presence, nobody would have signed up. Remember, everybody's first Twitter client was the web. If that sucked, or didn't exist, nobody would have bothered to pick up an API-based client.

However, Twitter later found that there were many problems with their system, and had to completely redo everything, to the point that '#newtwitter' now is just an interface that sits on top of their API.

So maybe it would have actually been cheaper in the long run to have built a perfect API first, rather than a web service followed by an API.

Yeah sure, even though nowadays more and more services where API IS the product are coming out...simplegeo, twilio, cloudant, mongohq, S3amazon...

API first is actually right in my opinion. Software is very multi-platform now : if you build the API first and then build the clients on top of that, you can make the clients completely decoupled from the server, allowing you to quickly switch platforms.

Technically, API first is a good thing. I don't know about from a business sense.

From a business sense you want to ship a minimum viable product as soon as possible. There may be teams that could do this most efficiently via the architecture you describe. I think most will work faster with one less tier.

Shipping an MVP with the most basic UI that gets JSON data from the server is fast and usable.

It was difficult to do this in the past, because browsers could not support the data that returned from the server without a lot of work. Today, JQuery that can present the data with minimum effort.

So much hate on the web these days. Mobile is great, so are APIs, but the web still has some life left. Don't count it out just yet.

Match your platform to your problem and expand as necessary.

http://ookaboo.com/

did web and API simultaneously -- mobile will happen when revenue or investment comes in and I can hire a team to do it.

The API has been a tough sell, however, because it's doing something entirely new. It's also got the issue that I don't know how to monetize it, whereas the web can monetize just fine. On the other hand, landing just one major API user can send me enough traffic that my competitors won't know what hit them...

After clicking around, I still have no idea what your app does.

image search that works.

Look for something on Google image search and typically the same image will show up in 25% of the first page of results and precision can be anywhere between 10-75%.

Image search is still so bad today that people don't even believe it can be made better. Defined in a certain narrow way, the Ookaboo API is > 99% accurate, however, there are common cases (categorizable) where its view of reality doesn't match other people's. For instance, Ookaboo might show you a picture of a person that is associated with a place instead of the place itself, or it might show you a picture of something that an artist made rather than show you a picture of the artist. We've got answers to that under development

Don't think I've heard someone phrase it this way, but I agree (in some cases) - API first is a good way to go, if only to enforce proper abstractions on the server side. We launched our product as an API only (and it still is) and then segmented some API calls as paid calls, and others as free. Our entire business so far is just very simple API calls. It's a remarkably efficient operational model since the payloads tend to be small therefore each response-request cycle is lighting fast.

I would amend this to something more like: find customers first, then build the thing they want in simplest way that satisfies their needs.

Another reason not mentioned is that you are giving your API credibility and testing it by using the API in your own product. You get to consider the different things that customers might want to do with your API and consider the strategic effects of including features x over feature y.

If you care about making money -- Mobile First, Web Second, API Third (though web and API kind of go together, so how about both at the same time? :)

It sounds like some people have just heard about multi-tier!

Reply on news.ycombinator.com