Looking at this list again it makes me think that HN is not in the category of web sites Fred is talking about. It's obviously successful, but it doesn't follow a lot of these recommendations.
In the comments he mentions "it makes the app shareable on blogs, email, social media if every resource/page has its own URL". That's true, unless of course when 75% of your URLs are behind authentication, which is true with every paid app.
So the connection between sharing and REST doesn't make much sense.
Why not just say: make it easy to share? Or provide clean URLs for APIs?
People who have never used a diversity of web APIs (>= 20) should never be allowed to design them, or I will personally fly to their dungeons and strangle them with their own lousy documentation strings.
Test your "API" with a variety of languages, that are not C++ clones. If you can respond with a header value, don't make me parse a body (i.e. responding with 200 when the body says "error".) Accept whitespace liberally. Space should mean \\s+. Not just a particular " ".
Version your API. Don't obsolete stuff willy nilly. Even if you're clueless, it's not too hard to run three instances of the endpoint app, and route requests to a per-version instance with URL rewriting proxy.
Anybody who has ever sat in the specification committee of a "microformat" should never EVER be allowed near APIs that others might use. Specification-creep is real; one draft spec by 3-guys in their dorm room creeping into another spec by some other guys. I can cope with IETF and W3C pulling stuff out of thin air, but I will NOT tolerate being told to read several draft-0.01a.txt specs from 2003, for a myriad of "social identity" crap that no one, but those whose name appears on the first page, cares about.
Also, offer a sandbox, and dummy instances with mock data. Otherwise I will rape your live servers in a tight, unrolled loop (Srsly, I am on a fat pipe, running native x64 code; your instance of Jetty or WEBrick will never know what hit it.)
And also, for the love of all that is holy, when you offer a sandbox and test data, give me a way to deliberately trigger error responses.
It's all well and good to give me an is_test parameter on your payment API, but if using it causes you to blindly approve all payments, I can't test all of the code paths dealing with all of the possible failure modes(true story).
Last client, travel biz, had APIs to many holiday and travel co's APIs. Some of the big ones, no names, had no mock data. Being travel data, live data changed by the second. Had to employ someone specifically to fix test data, and the tests, simply to allow the devs to work. Insane.
Corollary: The reason the travel industry is such as mess is its complete lack of understanding of, and refusal to engage with, its customers. It's really, really easy to fix, but the suits refuse to acknowledge the problems.
Far be it from me to question Fred Wilson, but I actually believe he is not referring to an API, but is referring clean URLs.
The reason I think this is because the second half (of the two sentences) on the RESTful section says "...every resource on your site needs to have a URL and ones that people can understand". Additionally, there is another section for APIs called "programmable".
Seems like a minor misnomer, but still a good point.
Clean URLs go such a long way towards making a system flexible. Being able to bookmark important items, being able to implement features with a simple hyperlink, and things like that.
REST is not just about being easy to share or for clean URLs. A service orientated architecture, such as REST in this case, let's you branch out to multiple clients outside of a web browser much easier and faster. Think iPhone, iPad, Android, BlackBerry, etc. By providing a read/write API, your other clients can easily consume your product and you will avoid the hassle of tailoring your backend for each individual client by remaining platform agnostic.
Interesting article about principles for designing a successful web app... if you're the only user. There are zero references to security mentioned at all. As a security engineer, this bothers me a little bit.
A lot of people don't understand that security holes in their applications aren't usually caused by a 0day in their framework, but instead sloppy security practices in the application itself. I break web applications for a living, and although I appreciate the consistent business, entrepreneurs and developers on Hacker News should understand that a critical hole will cripple their business.
Take some time before you let other people use your app (other than internal testing) and do a few simple checks:
- Am I sanitizing user-supplied input in my application? Can I throw a ' in a userid form, or will it break my SQL statements?
- If I put ''";<xss> in the search bar, and view source, are > and < symbols floating around the page?
- Am I relying on security through obscurity? This is a big one. "Oh, no one will find the hardcoded password in this world-readable configuration file six directories deep" is how infrasctructures get destroyed.
- Am I handling credit card data myself? Do I need to be PCI-DSS compliant?
These few questions will prevent 90% of XSS, SQL injection and CSRF attacks if you carry them out thoroughly. Don't realease a buggy webapp just to get hacked.
He's defining success in terms of potential popularity. I think security is important, but empirically, security seems irrelevant to most apps' popularity. Many apps have stayed popular after major security breaches.
I completely agree, and just wanted to reply to touch on this point a little bit.
You are correct that the article (rightfully) provides a forumula to create a popular app. Sure, there are lots of technical details that weren't touched upon in this article, and certainly we are not going to enumerate each of them and criticize the author for not creating an end-all be-all make-the-best-app-ever article.
However, I do believe that security should be a primary concern from the very start. Think about security early, think about security often. Once your app is already popular with 500k active users is not a good time to realize your oversight in security, leading to a possibly fatal breach.
I don't mean to criticize the article posted, and welcome many of the points myself. I am coming more from a software development perspective, although I understand that the article is geared primarily from a marketing point of view.
I agree with you that being paranoid about security instead of working on a human-friendly interface, or worse--a functioning product--will absolutely hinder developments to grow, but that is not what I'm suggesting. In my experience, the vast majority of crippling bugs are simple things, that can easily be prevented using methods such as the four I listed. These should be part of everyday secure coding practices.
I would never tell a developer that they should stop working on their product to tinker with obscure security fantasies, but I'd also say that they're crazy if they don't include basic checks (such as ensuring on a basic level that user input is clean) as mentioned above.
Development methodologies like TDD include this inherently in the software life cycle: tests reaching outer bounds and unexpected input are regularly created to make sure that errors are handled correctly.
I think a lot of points mentioned/not mentioned in this article are debatable...Security,Features,Target audience... But this article by Evan Williams is almost timeless( written in 2005, Pre Zynga, pre Facebook)
http://evhead.com/2005/11/ten-rules-for-web-startups.asp
22 comments
[ 4.3 ms ] story [ 56.7 ms ] threadRegardless, useful points worth keeping in mind.
In the comments he mentions "it makes the app shareable on blogs, email, social media if every resource/page has its own URL". That's true, unless of course when 75% of your URLs are behind authentication, which is true with every paid app.
So the connection between sharing and REST doesn't make much sense.
Why not just say: make it easy to share? Or provide clean URLs for APIs?
Course technically it doesn't _have_ to be REST, but that's the buzz of the now.
People who have never used a diversity of web APIs (>= 20) should never be allowed to design them, or I will personally fly to their dungeons and strangle them with their own lousy documentation strings.
Test your "API" with a variety of languages, that are not C++ clones. If you can respond with a header value, don't make me parse a body (i.e. responding with 200 when the body says "error".) Accept whitespace liberally. Space should mean \\s+. Not just a particular " ".
Version your API. Don't obsolete stuff willy nilly. Even if you're clueless, it's not too hard to run three instances of the endpoint app, and route requests to a per-version instance with URL rewriting proxy.
Anybody who has ever sat in the specification committee of a "microformat" should never EVER be allowed near APIs that others might use. Specification-creep is real; one draft spec by 3-guys in their dorm room creeping into another spec by some other guys. I can cope with IETF and W3C pulling stuff out of thin air, but I will NOT tolerate being told to read several draft-0.01a.txt specs from 2003, for a myriad of "social identity" crap that no one, but those whose name appears on the first page, cares about.
Also, offer a sandbox, and dummy instances with mock data. Otherwise I will rape your live servers in a tight, unrolled loop (Srsly, I am on a fat pipe, running native x64 code; your instance of Jetty or WEBrick will never know what hit it.)
Can you tell I have been debugging?
And also, for the love of all that is holy, when you offer a sandbox and test data, give me a way to deliberately trigger error responses.
It's all well and good to give me an is_test parameter on your payment API, but if using it causes you to blindly approve all payments, I can't test all of the code paths dealing with all of the possible failure modes(true story).
Last client, travel biz, had APIs to many holiday and travel co's APIs. Some of the big ones, no names, had no mock data. Being travel data, live data changed by the second. Had to employ someone specifically to fix test data, and the tests, simply to allow the devs to work. Insane.
Corollary: The reason the travel industry is such as mess is its complete lack of understanding of, and refusal to engage with, its customers. It's really, really easy to fix, but the suits refuse to acknowledge the problems.
The reason I think this is because the second half (of the two sentences) on the RESTful section says "...every resource on your site needs to have a URL and ones that people can understand". Additionally, there is another section for APIs called "programmable".
Seems like a minor misnomer, but still a good point.
A lot of people don't understand that security holes in their applications aren't usually caused by a 0day in their framework, but instead sloppy security practices in the application itself. I break web applications for a living, and although I appreciate the consistent business, entrepreneurs and developers on Hacker News should understand that a critical hole will cripple their business.
Take some time before you let other people use your app (other than internal testing) and do a few simple checks:
- Am I sanitizing user-supplied input in my application? Can I throw a ' in a userid form, or will it break my SQL statements?
- If I put ''";<xss> in the search bar, and view source, are > and < symbols floating around the page?
- Am I relying on security through obscurity? This is a big one. "Oh, no one will find the hardcoded password in this world-readable configuration file six directories deep" is how infrasctructures get destroyed.
- Am I handling credit card data myself? Do I need to be PCI-DSS compliant?
These few questions will prevent 90% of XSS, SQL injection and CSRF attacks if you carry them out thoroughly. Don't realease a buggy webapp just to get hacked.
You are correct that the article (rightfully) provides a forumula to create a popular app. Sure, there are lots of technical details that weren't touched upon in this article, and certainly we are not going to enumerate each of them and criticize the author for not creating an end-all be-all make-the-best-app-ever article.
However, I do believe that security should be a primary concern from the very start. Think about security early, think about security often. Once your app is already popular with 500k active users is not a good time to realize your oversight in security, leading to a possibly fatal breach.
I'd welcome a counter-example: can you name a succesful startup that died because of lack of early security?
The way it seems to work today on the Web is succeed first, get the money, then fix whatever needs to be fixed.
I agree with you that being paranoid about security instead of working on a human-friendly interface, or worse--a functioning product--will absolutely hinder developments to grow, but that is not what I'm suggesting. In my experience, the vast majority of crippling bugs are simple things, that can easily be prevented using methods such as the four I listed. These should be part of everyday secure coding practices.
I would never tell a developer that they should stop working on their product to tinker with obscure security fantasies, but I'd also say that they're crazy if they don't include basic checks (such as ensuring on a basic level that user input is clean) as mentioned above.
Development methodologies like TDD include this inherently in the software life cycle: tests reaching outer bounds and unexpected input are regularly created to make sure that errors are handled correctly.