3 ms·

Having a good API for everything would be almost as good as The Singularity (tm), but making a good and secure API is very hard and comes with a massive hidden

Having a good API for everything would be almost as good as The Singularity (tm), but making a good and secure API is very hard and comes with a massive hidden cost. 1) An API can require even more planning to design than the application or service itself. 2) Mistakes made in the design or implementation of the API turn into liabilities you can't solve without breaking users of the API. 3) The cost of maintaining an API so that it and its documentation doesn't fall out of date with the app/service can be as high (and sometimes even higher) as the cost of maintaining the app itself. 4) It widens the attack surface. And those are just the ones off the top of my head.

grncdr 17y ago
I agree with all of your points, but I think many of these costs are minimized by the other point mentioned in the OP: following the UNIX philosophy. The smaller and simpler your service is, the better. If you have a service that can't be accessed with a simple API, you probably have more than one service, and would benefit from splitting it into multiple APIs. Another thing worth mentioning is the possibility of building your API first, and then building your service on top of it. If you are providing a web service, then it [usually] boils down to data access and management. Figure out what data you are managing for your users and what you need to do with it, then build your API around that. If you plan to have a public facing API from the start, this approach makes sense (in the same way that using javascript only for progressive enhancement of a working site makes sense). Of course, because you are an "internal user" of the API, you can bend the rules a little more than the average client, but the less you do this, the more useful your API is. Regarding points 2 and 4: if public APIs for data access become the norm, this will simply become the cost of doing business. Secure API's aren't that difficult, and updating an API while maintaining backwards compatibility can be done, especially if you transition these changes and notify all broken clients.
- Periodic 17y ago
  For the UNIX philosophy I like the idea of small, useful tools loosely coupled. A big part of UNIX is that there are a lot of little tools that do one thing well. The smaller the tool is, less attack surface there will be, and each tool can interact with a common authentication/authorization interface to further simplify things.
- clawrencewenham 17y ago
  About building the API first: So many web apps are already built on top of an API or framework provided by a RAD tool. So if you build another API atop that then you'd lose the ability to enjoy the benefits of the RAD tool for the actual application--since it's now two levels away from it.

grncdr 17y ago

I agree with all of your points, but I think many of these costs are minimized by the other point mentioned in the OP: following the UNIX philosophy. The smaller and simpler your service is, the better. If you have a service that can't be accessed with a simple API, you probably have more than one service, and would benefit from splitting it into multiple APIs. Another thing worth mentioning is the possibility of building your API first, and then building your service on top of it. If you are providing a web service, then it [usually] boils down to data access and management. Figure out what data you are managing for your users and what you need to do with it, then build your API around that. If you plan to have a public facing API from the start, this approach makes sense (in the same way that using javascript only for progressive enhancement of a working site makes sense). Of course, because you are an "internal user" of the API, you can bend the rules a little more than the average client, but the less you do this, the more useful your API is. Regarding points 2 and 4: if public APIs for data access become the norm, this will simply become the cost of doing business. Secure API's aren't that difficult, and updating an API while maintaining backwards compatibility can be done, especially if you transition these changes and notify all broken clients.

Periodic 17y ago
For the UNIX philosophy I like the idea of small, useful tools loosely coupled. A big part of UNIX is that there are a lot of little tools that do one thing well. The smaller the tool is, less attack surface there will be, and each tool can interact with a common authentication/authorization interface to further simplify things.
clawrencewenham 17y ago
About building the API first: So many web apps are already built on top of an API or framework provided by a RAD tool. So if you build another API atop that then you'd lose the ability to enjoy the benefits of the RAD tool for the actual application--since it's now two levels away from it.