I’m a 21 year old person and I really don’t know anything about how to design an API. In my internship last year, I was asked to prepare a presentation on How to Design Social APIs (in Turkish). Today, I look at that presentation and laugh very loudly, indeed. :) Unfortunately, some of my points were just too preconceived and mainstream. Since that, I learned a few things more on this topic and maybe now I can prepare another presentation, but I won’t, because next year I’ll notice that how lame is that presentation, again.

Instead, I will show how not to manage a API design process for a social network, with a real life example of a multi-million dollar project.

Step 1. Be late, no hurries

Take your time and release API at least 1 year after you launch the social network. Who would use your API anyway? You don’t need a developer platform, mobile apps and lovely hacks, right? This might be one of the certain reasons of your failure. There are many hackers out there waiting to use your APIs and do cool stuff and utilize your network. Think about a Twitter without Twitpic.

Step 2. Do not use standards

Standards are for dummies. Dummy developers take advantage of standards just to write their apps easily. Don’t let them do this easily and make them read every damn line of your documentation.

Invent your own standards! Because you’re smarter than everybody in IETF and you are a perfect architect to design new **authentication protocols **[ 1 ][ 2 ] (RFC 5849), **date-time formats **(RFC 3339) and even a new JSON standard (RFC 4627)

Do not apply standards and engineering practices. They’re for lamers.

Step 3. Document your API poorly

There’s no need to be precise on actions and parameters on your API. Developers have a really good intuition and that’s a great virtue of them. They’ll just figure out how everything works instinctively. Most important of all, do not fix typos.

Step 4. Do not allow developers to edit or delete their apps

Because they created apps for your API once right? Why would someone need deleting or editing it? If they want to change, for instance, their callback URL, they create a new application and if they do this 30 times, they’ll have 30 apps on the management panel and that’s perfectly fine.

Step 5. Do not accept feedback from users

Everybody has an opinion and usually their opinions make no sense. They just send feedback to improve your poorly-designed API for FREE and you insult them (make sure that you’re being rude), then you say “we won’t fix this” without a reason. You only take orders from your boss and your boss probably doesn’t hear about feedbacks at all.

Unless it is given by your boss, don’t take feedbacks seriously, they are just extra workload for you.

Step 6. Expect patience and tolerance

Because your team is too small and you don’t have money, right? Talk about how bad your release pipeline, deployment cycle are, how busy you are on social networks. Expect patience and tolerance from developers, right?

Hell no. Everybody is sure that you have at least 10 developers and millions of dollars spent on this project and developers do not have to give a sh*t about excuses you created with your own hands.