14 ms·

The only serious API that isn't a corporate API is the Web. (There are of course some pre-Web Internet APIs that are still around but they're a lot less relevan

The only serious API that isn't a corporate API is the Web. (There are of course some pre-Web Internet APIs that are still around but they're a lot less relevant.) Write for the Web. Don't write for a platform that belongs to a single vendor. Look what just happened to that cool Face.com API. Yep, even "good guys" can get bought and their third-party developers get screwed. The Web is the platform.

Domenic_S 14y ago
You just have to make sure the interest of the company who owns the API and your own interests are aligned. Take two examples: Twitter: as a client developer, your interests are competing -- you want control of the stream, Twitter wants control of the stream. Guess who wins? PayPal: You want to process payments, they want to make money taking fees for processing payments. That API isn't going anywhere. I think the first case can be mitigated if there's a "developer account" that you pay for, and I've predicted that Twitter and Netflix will both come out with (paid) developer accounts in a short time. We'll see.
- nomnomnom 14y ago
  But that's not "making sure" at all - you're still at the mercy of others. Just because you pay them doesn't mean they can't discontinue the product, for example. Also, PayPal seems to have a horrid history of freezing accounts nilly-willy.. sure, their API might not go anywhere (as long as PayPal doesn't ;).. but what's the use when your access to it might go away any moment?
  - Domenic_S 14y ago
    "Making sure" may have been too strong of a phrase; what I'm talking about is minimizing risk. Sometimes you can form relationships or partnerships with the 3rd party, sometimes you can shovel them money, and at all times you should do your best to make sure you're not using a 3rd party to compete with itself.
- blake8086 14y ago
  "Making sure" is signing a contract with them. That's what contracts are for.
  - spindritf 14y ago
    Can you afford to actually enforce a contract against a much larger company? Are you willing to waste all that time and resources?
    - blake8086 14y ago
      Ok, I apologize for the tone of my previous post, it was pretty flippant. Yes, I don't think you should even go into business without either: 1) A reasonable expectation of getting screwed (maybe reasonable is less than 1%, maybe it's 50%) 2) Money to pay at least some legal fees In order to ensure fairness, you have to play some kind of game of attrition http://en.wikipedia.org/wiki/War_of_attrition_(game) http://en.wikipedia.org/wiki/War_of_attrition_(game) against others who would seek to gain by harming you disproportionally. In the U.S., we usually play that game with lawsuits. Perhaps in Russia (I am broadly generalizing and stereotyping) you might play it with bribes and cronies. In Somalia, it might be with actual guns and attrition. You can enforce a contract against a larger company, size does not have a 1-to-1 correspondence with court case outcomes. Again, sorry for sounding like a big jerk.
EGreg 14y ago
Actually, it's any platform that has a well documented protocol and open source reference implementation. Email, IRC and XMPP are other ones that comes to mind.
pjmlp 14y ago
> The Web is the platform. The network is the platform, web is for documents.
stiller 14y ago
Just never cross Google.
gbog 14y ago
> The Web is the platform. I am not sure to get exactly what you mean with that. But I was thinking about APIs recently and I will explain how I think it should be done in the best of the worlds, it may have some relation with this assertion. First a note: I don't mean APIs can be like what I describe, nor that businesses should do like that, nor that it is easy or has no problems. It is just a point drawn in the plane for better distance measures. When I point my browser to http://someurlfoo.bar/user/A http://someurlfoo.bar/user/A, the server knows I am using a browser, knows who I am, and answers with a mix of HTML, javascript and other resources. Now if you check any API available you almost always have an equivalent GET http://api.someurlfoo.bar/user/A http://api.someurlfoo.bar/user/A, and the server will answer with some XML or JSON blob containing the information required (and often more). Setting authorization, optimization and bandwith issues aside for 5mn, one could just wonder why the ### those two interfaces are different. Why not read the ACCEPT header and answer with JSON, XML or HTML accordingly, serving apps, direct users and other client through the same dumbwaiter? Why not having just one interface? Benefits would be interesting: - user A would be able to present itself ("A, the name's A") in different languages: html, xml, json, whatever. - the information about a given topic should have the same content in every languages. Just take the data from the store and filter it through a jsonizer, an xmlizer or a htmlizer. - API client code would not have to read awful API docs that are obviously written by robots for robots: they would just change point their browser to the data they want, change the accept header to json and get their answer. It seems to me that, APIs having historically grown after normal web pages, they have been conceived as a separate service, but they are just the same core thing. Now let's go with possible objections: - Authorization should be handled the same way, but it is possible that the server would need to ensure that you are coming from which mobile app, or web app. It is easy to do with a double authentication: the app authenticate itself and passes along end user authentication token. This way the server knows who it is speaking to, through which intermediaries. - Bandwith: An important use for APIs nowadays, from the server's point of view, is the ability to avoid being flooded by bogus requests. An API key comes with limitations on the maximum amount of requests per day or the like. If both the end user and the client app authenticate themselves, then there should be no difficulty in giving priority to some clients over others (usually the direct browser access is preferred). - Optimization: This is maybe a bigger issue. From the APIs I have seen they seem carefully crafted to reduce the number of roundtrips required. For instance, a GET request for user/A might answer with A's name, number of followers, list of recent followers, same with followings, A's recent posts, creation date, last dog-walking time and culinary preferences. All of this makes no sense if all you need is A's full name. I think this optimization issue should be solved differently, even if we were to keep the current isolated status of APIs, but this if for another post. Edit: s/hatch/dumbwaiter/

Domenic_S 14y ago

You just have to make sure the interest of the company who owns the API and your own interests are aligned. Take two examples: Twitter: as a client developer, your interests are competing -- you want control of the stream, Twitter wants control of the stream. Guess who wins? PayPal: You want to process payments, they want to make money taking fees for processing payments. That API isn't going anywhere. I think the first case can be mitigated if there's a "developer account" that you pay for, and I've predicted that Twitter and Netflix will both come out with (paid) developer accounts in a short time. We'll see.

nomnomnom 14y ago
But that's not "making sure" at all - you're still at the mercy of others. Just because you pay them doesn't mean they can't discontinue the product, for example. Also, PayPal seems to have a horrid history of freezing accounts nilly-willy.. sure, their API might not go anywhere (as long as PayPal doesn't ;).. but what's the use when your access to it might go away any moment?
- Domenic_S 14y ago
  "Making sure" may have been too strong of a phrase; what I'm talking about is minimizing risk. Sometimes you can form relationships or partnerships with the 3rd party, sometimes you can shovel them money, and at all times you should do your best to make sure you're not using a 3rd party to compete with itself.
blake8086 14y ago
"Making sure" is signing a contract with them. That's what contracts are for.
- spindritf 14y ago
  Can you afford to actually enforce a contract against a much larger company? Are you willing to waste all that time and resources?
  - blake8086 14y ago
    Ok, I apologize for the tone of my previous post, it was pretty flippant. Yes, I don't think you should even go into business without either: 1) A reasonable expectation of getting screwed (maybe reasonable is less than 1%, maybe it's 50%) 2) Money to pay at least some legal fees In order to ensure fairness, you have to play some kind of game of attrition http://en.wikipedia.org/wiki/War_of_attrition_(game) http://en.wikipedia.org/wiki/War_of_attrition_(game) against others who would seek to gain by harming you disproportionally. In the U.S., we usually play that game with lawsuits. Perhaps in Russia (I am broadly generalizing and stereotyping) you might play it with bribes and cronies. In Somalia, it might be with actual guns and attrition. You can enforce a contract against a larger company, size does not have a 1-to-1 correspondence with court case outcomes. Again, sorry for sounding like a big jerk.

EGreg 14y ago

Actually, it's any platform that has a well documented protocol and open source reference implementation. Email, IRC and XMPP are other ones that comes to mind.

pjmlp 14y ago

> The Web is the platform. The network is the platform, web is for documents.

stiller 14y ago

Just never cross Google.

gbog 14y ago

> The Web is the platform. I am not sure to get exactly what you mean with that. But I was thinking about APIs recently and I will explain how I think it should be done in the best of the worlds, it may have some relation with this assertion. First a note: I don't mean APIs can be like what I describe, nor that businesses should do like that, nor that it is easy or has no problems. It is just a point drawn in the plane for better distance measures. When I point my browser to http://someurlfoo.bar/user/A http://someurlfoo.bar/user/A, the server knows I am using a browser, knows who I am, and answers with a mix of HTML, javascript and other resources. Now if you check any API available you almost always have an equivalent GET http://api.someurlfoo.bar/user/A http://api.someurlfoo.bar/user/A, and the server will answer with some XML or JSON blob containing the information required (and often more). Setting authorization, optimization and bandwith issues aside for 5mn, one could just wonder why the ### those two interfaces are different. Why not read the ACCEPT header and answer with JSON, XML or HTML accordingly, serving apps, direct users and other client through the same dumbwaiter? Why not having just one interface? Benefits would be interesting: - user A would be able to present itself ("A, the name's A") in different languages: html, xml, json, whatever. - the information about a given topic should have the same content in every languages. Just take the data from the store and filter it through a jsonizer, an xmlizer or a htmlizer. - API client code would not have to read awful API docs that are obviously written by robots for robots: they would just change point their browser to the data they want, change the accept header to json and get their answer. It seems to me that, APIs having historically grown after normal web pages, they have been conceived as a separate service, but they are just the same core thing. Now let's go with possible objections: - Authorization should be handled the same way, but it is possible that the server would need to ensure that you are coming from which mobile app, or web app. It is easy to do with a double authentication: the app authenticate itself and passes along end user authentication token. This way the server knows who it is speaking to, through which intermediaries. - Bandwith: An important use for APIs nowadays, from the server's point of view, is the ability to avoid being flooded by bogus requests. An API key comes with limitations on the maximum amount of requests per day or the like. If both the end user and the client app authenticate themselves, then there should be no difficulty in giving priority to some clients over others (usually the direct browser access is preferred). - Optimization: This is maybe a bigger issue. From the APIs I have seen they seem carefully crafted to reduce the number of roundtrips required. For instance, a GET request for user/A might answer with A's name, number of followers, list of recent followers, same with followings, A's recent posts, creation date, last dog-walking time and culinary preferences. All of this makes no sense if all you need is A's full name. I think this optimization issue should be solved differently, even if we were to keep the current isolated status of APIs, but this if for another post. Edit: s/hatch/dumbwaiter/