4 ms·
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 you
by pilif 16y ago
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.
- RyanMcGreal 16y agoI 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.
- Charuru 16y agodeja vu. I feel like I saw this exact comment before on HN. I can't find the HN post though.
- wlievens 16y agohttp://news.ycombinator.com/item?id=1931799 http://news.ycombinator.com/item?id=1931799 I found it because I commented on it and had the same deja vu as you did :-)
- pilif 16y agoI too talked about this before: http://news.ycombinator.com/item?id=1882782 http://news.ycombinator.com/item?id=1882782
- JoelSutherland 16y agoI left that comment. My colleague just wrote up our process: http://news.ycombinator.com/item?id=2032346 http://news.ycombinator.com/item?id=2032346
- cmelbye 16y agoI 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)?
- pilif 16y agoYou 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.
- jsarch 16y agoAnother 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).
- andrewmccall 16y agoThe 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.
- wiseleo 16y agoWe 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. :)