Fred Wilson's 10 Golden Principles for Successful Web Apps • Hacker News Board

Re: Fred Wilson's 10 Golden Principles for Successful Web Apps

#21

Post by jcromartie » Fri, Oct 08, 2010, 12:59 PM UTC

dmix wrote: post #5

Why is REST relevant to a web apps success? 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…

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.

Re: Fred Wilson's 10 Golden Principles for Successful Web Apps

#22

Post by stevefink » Fri, Oct 08, 2010, 1:05 PM UTC

dmix wrote: post #5

Why is REST relevant to a web apps success? 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…

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.

Re: Fred Wilson's 10 Golden Principles for Successful Web Apps

#23

Post by auxbuss » Fri, Oct 08, 2010, 8:03 PM UTC

mahmud wrote: post #12

auxbuss wrote: post #8

Earlier quoted context omitted.

I agree. Eat your own dog food. Use your own API. If you aren't doing that, in most spaces, then there's more friction to scaling. Course technically it doesn't _have_ to be REST, but that's the buzz of the now.

But do it right. 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…

Don't I know it.

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.