Hacker News Reader

Comment by pilif | Hacker News Reader

The best thing to do would probably to be dogfooding your API from the beginning. To do that, only expose your business logic over your REST API.

Then make your website use that API and nothing else.

That way you are reasonably sure that the API scales, has enough features and is convenient to work with.

View on HN

I can't emphasize enough how much I agree with this. Since I started "dogfooding my API", my applications have gotten cleaner and more logical and my APIs have gotten a lot more usable.

deja vu. I feel like I saw this exact comment before on HN.

I can't find the HN post though.

http://news.ycombinator.com/item?id=1931799

I found it because I commented on it and had the same deja vu as you did :-)

I too talked about this before: http://news.ycombinator.com/item?id=1882782

I left that comment.

My colleague just wrote up our process: http://news.ycombinator.com/item?id=2032346

I want to do this, but I'm not sure how to handle authentication. If you were to do this dogfooding approach in a new application, how would you handle internal authentication (from your frontend) and also how would you handle customer authentication (from their client apps)?

You have multiple options.

If you use SSL, then it might be easiest to just use http authentication, transmitting the users credentials for each request, which is also the only official restful solution (each request should be independent of each other request).

If you don't want to do that, create an endpoint that takes username and password and returns a token which must then be present in each request (maybe even as part of the authorization header).

Or use OAuth.

Another option is the use of API keys that are separated into two types -- partners and end-users. The partner API keys would be bound to a particular end-point (e.g., the IP address of the web server) while the end-user API key could be used from anywhere (e.g., from a mobile device).

The OAuth 2 spec addresses some of these points by providing the user-agent flow.

The only place where it falls down some is when it comes to actually creating users. It's fine with one of the other flows because you can authenticate as an application with client credentials.

We are working on that even though it initially slowed down the development process. It changed my answers when talking to potential partners from "You can embed our widget" to "You can make an API call and either display our widget or manipulate the data we return as JSON however you want."

Guess which answer is getting me a lot more interest. :)

Reply on news.ycombinator.com