The Fosk Blog

The biggest fear for API providers is to get stuck maintaining deprecated API versions or support some kind of retro-compatibility for them, while the biggest one for API consumers is to see API implementations change and break their client implementations. As an API consumer, I always fear that one day an API provider may just decide to change his API or release a new version that would break my applications (and usually that happens at Chrismas Eve).

Basically API consumers are worried about facing the most common scenario in the computer/software industry, that is: implementations always change. So you're an API provider and you have released an API that other developers are consuming right now, but you can't substantially update it because you're worried to break their client implementations and make them angry with you.

You probably need an API versioning strategy. Let's start migrating.

Last month I had to change my phone number, it meant that I had two phone numbers on two separate phones that I always carried with me. I then started to give my new number to my closest friends that I meet everyday, but that wasn't enough because all the other people still used to call me on my old number. And that was a problem. Basically every time someone texted/called me I asked to delete the old number and switch to the new one. Eventually after one month all the people I really cared about were texting or calling me on the new number, so I could just shut down the old one. What I did was to gradually migrate my friends to the new phone number and then deprecate the old one. I think that this could be a viable strategy for updating an API as well.

A good roadmap would be to release a new API version, but still keep maintaing the old one. This means that while developers find some time to update the clients, their implementations will still work with the old API. Regularly notify them (email, sms, add warning boxes to the documentation) and track those who have already migrated and those who are still using the old version. Give to them some reasonable time, 2/3 months or maybe more, to migrate and then just gradually shutdown the old implementation. Developers probably don't want to keep consuming a deprecated API, so as soon as they found out that a new version is available they will take all the necessary steps to migrate to the new one, just give them a good time window. In the meanwhile you'll basically support both versions at the same time (and maybe, if needed, have two different, but parallel, infrastructures up and running).

There are different strategies for keeping two different API versions running at the same time. You could use different DNS endpoints for each version, or properly route requests by reading the submitted Accept header. I would focus on one API version at a time, so I wouldn't keep the old one running forever.

For more resources, I would suggest reading the first answer of this Stack Overflow question: http://stackoverflow.com/questions/389169/best-practices-for-api-versioning

While for a nice workflow using the "Accept" header, I would suggest taking some inspiration from this implementation: http://files.zend.com/help/Zend-Server-Community-Edition/api_versioning_negotation.htm

"Here's to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They're not fond of rules, and they have no respect for the status quo. You can quote them, disagree with them, glorify and vilify them. About the only thing you can't do is ignore them because they change things. They push the human race forward. And while some may see them as crazy, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do."

I still remember the days when Yahoo! Pipes launched, and a lot of people was saying that it would become a game-changer because everybody finally had the tool to easily create a piece of software, or a mashup, without coding. After so many years, it's career can't be considered successful. And also, Google App Inventor, to easily create Android apps. At first I was excited about it - but then the market has made it slowly fade into the oblivion.

These tools were targeted to Excel guys, wannabe developers and anyone who magically wanted to create something without learning a programming language. The problem wasn't in the product itself (ok, there's always margin for improvement), but in the vision. Most of the people targeted by these services just don't want to create anything.

There's a lot of people who may be excited to have a tool that allows them to create a piece of software without coding - but that's it, they're just excited for the idea. At the end of the day, sitting on their sofa holding their iPads people just want to consume content, and even if they had the real opportunity to create something, they wouldn't. Because they're consumers, not creators nor developers. It's not a matter of tools. Who's not a developer, has no interest in creating a piece of software by himselft. I can bet most of the financial "pipes" on Yahoo! Pipes are made by developers, not by Excel guys.

Consumers create content, not applications. Developers create software, waiting for users to create content. That's it.

Finally Mashape supports every existing JSON API, via an open XML specification.

Your API can now be distributed into the marketplace with thousands of hungry developers ready to hack on it, and it will have five auto-generated client libraries, an API profile with custom link for signup/login, easy authentication, and you can choose to put the addons on top of your API infrastructure: the API Request Limit and very very soon (aka, next week), a Billing addon (for selling your API). I'm looking for suggestions to create new addons :)

So if you have a JSON API, with some methods like:

• GET http://www.myapi.com/users

  That returns, for example, the following JSON response:

• POST http://www.myapi.com/users?name=John&email=john@myapi.com

  That may return:

You can distribute them with the following XML file:

Basically we're describing the methods available, their parameters and their response objects. There's a tool to easily generate the XML representation of response objects

Also, we have updated our open source PHP Library to support the new specification, and now developers can easily create any other implementation by following the specs.

It may be funny we're using XML to describe a JSON API, the reality is that this description is more like a document than a struct :) Also we needed to keep retro compatibility with our existing server library. JSON specs are on the roadmap.

Let me know what do you think :)

One day some months ago I was browsing my projects folder to clean up the mess after years of development. I found among all the files some useful pieces of code, and I thought why I was keeping them lost in there when maybe they could be useful not only to me, but also to other developers. I wanted them to be callable and put in production in a second with an API, and also I thought it would be nice to make all these components available in a search bar: Mashape was born.

So Mashape is an API marketplace for any kind of service and component, where developers can list new APIs and let Mashape auto-generate 5 different client libraries (PHP, Ruby, Python, Java, Objective-C), write a nice documentation with examples through a wizard, and *soon* monetize them (yes, it's a marketplace).

To make this possible, I needed to give a base interface to every component, so I've created a open source PHP library that integrates with Mashape to easily create a beautiful RESTful API that automatically handles and authenticates HTTP requests and serializes the responses. A Rails plugin is on the roadmap. Lately I was thinking to create also a RESTful API for Mashape, to easily list existing APIs in the marketplace downloading a client library rather than a server library.

You can use Mashape to to generate QR codes, pretty print a JSON string or get weather forecasts. More complex components exists, for example you can resize an image or read the New York Times. You can put any component/service into the marketplace.

Right now I'm looking for more feedbacks to improve the service. I think that with your help we can make Mashape a better service - I also wanted to thanks the Mashape community for their valuable help, some of you guys already have actively contributed to our cause.

For any question or feedback you can send me an email at marco[at]mashape[dot]com

You can find Mashape on Twitter: @mashape

We always dream. No matter where we are, who is with us. We dream for the pleasure of an high flight.

We fight to make our dreams real, and hardly happens. We know that, and we get excited.

We work 18 hours per day, we are stressed, we don't eat, we meet anybody. When we should sleep, we keep working on the desk. When we should eat, we eat on the desk. When we need a fresh breathe, we keep working on the desk. When we should piss, we keep working on the desk. When we want a beer, just then we stand up looking for it.

After all the work we do, we never get the expected results. And the more we try, the more different results we get. Considering that, we keep working and forecasting results that we know will never come.

We want to change the rules, we want to change the world, we want millions of people using what we're building now with a computer and some beers, without money nor certainties.

It's like a game source of adrenaline, without it we couldn't try to discover new ways of doing things that nobody would have never bet. Sometimes we succeed, sometimes we fail. And when we fail, it's nothing but the game becoming more interesting.

Because we're all insane. And it's the right way to be.

1. Do not try desperately to find an idea

   The market is the intersection between the supply and the demand. Find a need, and fulfill it with your product. It's so simple that at some point you could start to ignore this. So always remember that it's something you're going to ship, it's not some kind of research.
   Something that people will pay for. Will you pay for it?

   Here is a nice article written by Paul Graham on the topic: http://www.paulgraham.com/organic.html

2. Find a partner

   This is not the rule, but if you want synergy, if you want to have someone that gets you up when you're down, to share the risks or to cover the business side you can't do by yourself, then I'd suggest you to look for a co-founder. I'm a software developer, and building a product it's so much time and mind consuming I couldn't deal with the business aspects. This is why I had needed a co-founder that completed my lack. If I run, he runs faster, then I run faster than him and so on.

3. Be aware you are becoming an entrepreneur

   You'll not leave the troubles on your desk at 6pm like an employee. You will work on your product every time, day and night makes no difference. You will sleep bad thinking on the daily problems, and when you wake up you will need to meet always new people and looking for feedbacks, crushing on events and parties. You will need to handle the pressure from the outside: your friends will think you're crazy because of all the time you've been spending on something that doesn't give rewards, and you will not have time to see them, as well as your family, like before. You will cut drastically (although not totally) your social life. Because your startup is your life, your wife and your girlfriend, and your real girlfriend will be your lover.

   Jamie Zawinski (http://www.jwz.org), when he answered a question in "Coders at Work" (http://www.codersatwork.com) regarding the long hours required for building a product, said:

   "It's certainly not healthy [...] So the way to answer the question is, is there another example of someone delivering a big piece of software that fast that's of reasonable quality where they actually had dinner at home and slept during the night?"

   Because of your emotional and physical involvement in your business, when something will start to creak your dreams will soon become your nightmares.
   And you will feel the failure right there, on your side. And maybe, at the end of the story, you could fail.

4. Don't waste money

   The things you don't have are: time and money.

   Don't rent an office, don't buy a new computer, don't spend money in something that isn't strictly required for your project. Don't buy pens, you can take them at some event hosted in some hotel. Don't go to lawyers, don't do all that.
   Spend some money for your business cards and buy some beers, that's it.

5. Answer all the questions before you start

   If you have doubts, spend some time to solve them now, otherwise you will have to find a solution at the end after months of work, and it's not a good strategy. A good entrepreneur is not only who has the strength to do something, but also who can forecast the future. You can't change the future, so if it's bad, change your product. Your mental flexibility to change what your doing, sometimes paying something for it (aka: cutting half of your lines of code), is the key. Paypal has changed direction 4 times before becoming the company we know.

6. Just do it

   Start doing something. Don't look around for “positive signals”, or something like that. Don't waste your time, 'cause you don't have time. It's time to stop speaking, and start acting. Your results will be measured by the facts. Take your risks, otherwise start looking for a regular job. Behave like an entrepreneur, don't be shy.
   Set a roadmap with milestones, and work hard to respect deadlines. If you start to miss one, then you will miss all the others and you'll be 5+ months late for the release.

   If you're in the wrong place, try to go where you have more chances. Every job has it's own place: if you're doing finance, go to New York or London (or Hong Kong, etc), if you're doing IT then the best place will be San Francisco. If you're in Nebraska It's unlikely you will succeed in the fashion area, go to France or Italy instead.

   I know it could be difficult to make such a strong decision, and again, this is not the rule, but remember that when it comes to start a company it's all about having more chances to win, it's not about sentimentalism.

7. Lunch a product and get feedbacks

   It's not a good idea to keep working in your garage without having feedbacks from the outside and, most important, by some people using your product.
   Your role is to find a need and to give a basic and essential solution for it. Most of the time you will be tempted to add additional features based on what you think could be right for your users. And most of the time your needs are not your user's needs. Release it as soon as possible, and then iterate over their feedbacks.
   Dave McClure (http://www.500hats.com) says that if something takes more than 6 months , then it's going bad. I can't remember who said this, but "If when you've lunched your product you're not embarassed, then you have waited for too long".
   I can't find an entrepreneur who hasn't made this huge mistake. And it's ok, it's a natural process like when you discover for the first time the fire is hot, so make your experiences. It's just good to be aware of it though.

   Again Jamie Zawinsky comes in rescue here, when he answered another question in Coders at Work:

   “At the end of the day, ship the fucking thing! It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point.
   You're not here to write code, you're here to ship products.”

   The nice part comes here, when people are spending some of their time using your product, and you're somehow making their life better.

8. Iterate

   When you've lunched your product, then your users will ask new features and just then you will add them. Learn when to say "No" and when to say "Yes". Not all the features they are asking for could be good for your business, evaluate them carefully.

9. Fewer is better

   The smaller you are, the better. Don't hire people for tasks that aren't strictly required. If somebody in your team can somehow do them, then it's not time to look for a new employee. When the tasks are too many that you can't handle them, it's time to optimize the processes to make them manageable.

   When it comes to hire someone, it should be the last option. The penultimate is you working on your desk at Xmas.

10. Look at your side..

    The failure is still waiting there, where it was and where it will be. Defeat it!

    Cheers!

    Marco

Considering happiness as a competitive advantage could be cynical, but it shouldn't be underestimated when running a business.

So, as someone might know, I'm in SF doing Mashape, and running up and down through the city for meetings and events leads me to eat where I can: when I'm lucky a great dish of pasta on a real table, but more often a big cheeseburger in a cheap fast food chain.

Two days ago I had the chance to choose between two different places, and simply I've chose the one where the environment made me feel better: in particular, it happened more than once to go there, and I like how the employee welcomes the customers. She is always nice and welcomes you with a happy smiling face. For education, I smile too because of the positive energy she transmits.

Now, when I'm in that area and I need to eat, I always go there. If I have to choose a place, I would go where the experience is better: considering that the large fast food chains have almost all the same sad atmosphere, I can say now that I go there because I'm welcomed better that the other places.

If a company is happy with me, I'm happy with them. If the customers of a company are happy, the company will be happier.

Happiness is a positive energy that gives value to the customer-company relationship through all the levels:

• Commercial: Between a non relevant difference between quantity/quality, my propensity to buy or not a product is guided by the experience I have during the decisional process. If you make me happy, you increase the pleasure of the selling experience. You get a point. 

• Corporate Image: It's better to be known as an happy company than as an old and sad enterprise. Obviously this depends upon your industry and your customers. You're trying to sell products to a market, that is an agglomerate of people, then you have to build your image around them and their expectations. Nobody is expecting you to be sad, they don't care about your personal and sentimental problems and so on. If you're happy, they will be happier to spend more time looking what you have to offer them. That's what matters. 

• Marketing: If your image is good, your marketing activity will run on a speedway, instead of unpaved roads. 

• Work: It's known that most of the people behave accordingly to the environment where they live or work, so If you're company has promoted an happy environment, your employees (what a bad name!) will reflect that positive sensation in their ordinary job. The results will be better.

The point is that people unconsciously relate your happiness to your product. And when you meet them, you're representing the product. If you're happy, and it's established that is a good feeling, people will associate it to what you're trying to sell them.

Below some nice slides about the topic:

Hello World, this is my first post!

I've been seeing for years my closest friends and business partners writing on their blogs, and while I've always considered blogs as one of my most important sources, I've never sat on a chair to try to write something to the whole world (wow!).

And yes it's strange, because I've always loved to write, from poetry (third regional place when I was 14) to novels (I was 19, and that love book of 170 pages still is one of the most cozy things I've ever done), and generic piece of writings that made me somehow feel free in bad, or good, moments.

That was the point: writing was for me something private, personal, not to be shared. I thought that If I wanted to share my opinions with someone, then it would be done speaking face to face like I always done with my parents, with my friends, with my partners. Simply because I thought, and I think, it's the best immediate way to feel the difference between different opinions. Stephen Covey teaches to find ways to leverage individual differences (The 7 Habits of Highly Effective People), and I found it in direct conversations. When I felt that something shouldn't be appealed, then paradoxically I wrote: the sensation to put my feelings and opinions down in black and white gives to my words the strength not to be countered, and whatever word was said against them then I thought: hey! They are written now, and what people thinks about them it doesn't matter for me as the word on a paper is stronger than the word floating in the air. Writing for me was the communication of what I deeply felt inside, thus who read my piece of writings could just accept them as they were.

And now tonight I'm on my chair, to be challenged by unknown people (though it's a small world, pay attention!), and yes: I've mutated my opinion (in Italy, but maybe also in the US, there's a saying “Only stupid people don't change their idea”. Personally I always got angry when someone had told me this sentence, and then I always replied “Are you sure?”: usually the response was quite often: "Yes".....got it? :).

My name is Marco, I'm a software developer, entrepreneur, co-founder of Mashape, and italian. I'm 21, and I'm going to write on my new blog tech articles and love articles, through general considerations and thinkings. The aim is to share the things I know with you, and to assimilate your feelings about them, positive and negative (better if negative, do you remember the leveraging of differences? As someone said, when I speak with someone that totally agrees with what I'm saying, then I feel that I'm saying something wrong). And, of course, to learn something new hoping that this experience will make me somehow become a better person.

The blog is named Sinz because It was my tag when I was younger and when with my friends Norba and Nobel we were tagging all the city. Since then, somebody still calls me Sinz – a lot of people to be honest, and it's my nickname. So, I gave this name to my blog because I want to start this new experience with a foot in the future, as it's something I'm doing for the first time and to whom I've some expectations, and in the past, by preserving my old nickname: like happens in life, in every decision, past and future are always part of us.