The Universality of APIs

The client should never ever decide how the server should response.

A few days ago, I was faced by the options to choose whether our API design should compromise its universality by changing the response in a non-standard format or stick with the original design. The need to change the API to the non-standard format came from one of its clients because they have some virtual restriction on how to process the response.

Let me explain that a little bit.

Recently, we have a project with one of telco companies here and we need to be able to open the API to talk to the SMS Gateway as well as IVR. We have defined a set of rules that should never be changed unless the end of the world is near. One of the API is a resource which can store the data into the database based on user’s SMS.

Let’s say that a user type these into their phone and send it as a text message to our server:

REGISTER John Doe#12345678#10-04-2002#Jakarta

and the user, John, will get a lot of information from the server like this:

Welcome, John Doe. It’s nice to meet you here and we welcome you to our brand new service. There are 102,452 people behind you waiting to access this service and can’t wait to join the new era of communication. Once again, congratulations on your joining today and here is your username along with a password. Username: johndoe. Password: johndoe123.

The backend will look something like this:

John Doe send a text message to a short number, 1234, and the phone will send it through MSC and SMSC. SMSC forward the packet to SMS Gateway and the SMS Gateway will forward the information to the server. The server’s response will be accepted by SMS Gateway and it will forward to the SMSC. SMSC to the MSC and finally, the user get the response from MSC. (Fiuh, what a confusing world we lived in).

So, why is it all related to the universality of APIs?

We discuss further on how to make a long response fit into user’s phone without even a single word being broken. As we’re already know, SMS is limited to 160 characters and we have the response exceeds this limitation, it will gonna break into two or more text messages. It’s fine. No problem with that.

The actual problem is that we don’t want to break even one word to be two pieces which became no meaning at all. Take as an example: welcome become wel come, communication become commun ication, and so on. This is not good.

So there comes the idea to break the long response into pieces and every pieces is no longer than 160 chars.

But how?

One of our team suggest that the server response would be something like this:

    'status': 'OK',
    'code': '200',
    'data': {
                   'response': 'register_ok',
                   'response_txt': 'Welcome, John Doe. It\'s nice to meet you
                       here and we welcome you to our brand new service.
                       There are 102,452 | people behind you waiting to access
                        this service and can\'t wait to join the new era
                        of communication. Once again, congratulations
                        on your joining | today and here is your username
                        along with a password. Username: johndoe.
                        Password: johndoe123.

(If you noticed that I’m putting the pipe ‘|’ there, yes, you’re right. That is the separator for every 160 chars. Even though I didn’t put it exactly at the 160th char. This is just for illustration.)

This suggestion sounds very good and fix the problem. But be aware that this problem also break the API’s rule, universality (or in other term generality), and potentially create problems.

So what’s the problem?

So with the new API, the SMS Gateway is able to split the long response into pieces, each pieces has no longer than 160 chars. Everyone happy. The SMS Gateway is happy. The user is also happy (or maybe don’t care at all). But what about another third party app (such as Android or iOS client) that decided to use our API?

Yes, they have to split the response also. Or the proper way to do that is to strip the separator ‘|’ char from the response. But it’s not a proper way either. And suddenly, all third party clients questioning and complaining our API why in the world we always putting pipe in the middle of our response?

The Solution

The client should never ever decide how the server should response. We rolled back the API to the way it used to be –long response without the ugly pipe– and we suggest this simple function written in Python to solve the SMS Gateway problem:

def split_to_sms(txt):
    results = []
    txt_temp = txt

    while len(txt_temp) > 160:
        cut_pos = string.rfind(txt_temp, ' ', 0, 160)
        results.append(txt_temp[0 : cut_pos])
        txt_temp = txt_temp[cut_pos + 1 : ]

    if len(txt_temp) > 0:

    return results

We put the code in the client (SMS Gateway) and everybody is now really happy (the user still don’t care though, the response is much the same as before.)

Problem solved without compromising the API’s design principle.

Automate, Automate, Automate

As a programmer, I always encourage myself and others to be lazy.

No, I’m not kidding. Programmers should be lazy.

In my early days as a professional programmer, I worked like crazy. I like to do something manually. I like to type a command like javac, java happypuppy.class and if there were errors, I also like to type setenv CLASSPATH ... happily. Manually. Without doubt.

When it comes to web development, I would zipped all the php files needed, sent it through ftp or scp (manually or by using tools like FileZilla or Cyberduck), unzipped it on the server side and opened the browser to test whether it’s worked on the server or was something broken there.

Building Android application was a little bit messy. I tested the code against my environment (and my emulator), I compiled and built the code manually using Eclipse and then take the individual apk file to be signed using command line. After that, I uploaded the apk to the server and let others to try. If bug was found, I would fix that bug on my local machine, re-compiled and re-built it using Eclipse. Take the individual apk file to be signed, uploaded the apk and let others to try again.

I might not realize that someday I would be terminated from this world knowing that the cause of my termination is an infinite loop. I hope not.

I learned very much in those process and I would never regret that I have ever been a ‘diligent’ programmer. I might not knowing anything if I just jumped over the process and using some tools that were just made to make my life easier. I might just said that I learned the hard way.

I started to understand the SVN and Git. I started to use bash script and Python script as much as possible. I started to learn Ant as part of Java build tools (you guessed it. It solely for Android). I started to get my feet wet with Hudson and Jenkins. I started to play with JUnit, Robotium, and Selenium. Bunch of tools I learned that makes me what I am today.

After all those things, I arrived at the conclusion that programmers should be lazy.

Reasons? Continue reading

Playing with Audio in HTML5

Recently, we had a little challenge on how to record our own voice using microphone with a very minimum effort from the user and store it in the cloud. What I mean with a minimum effort is that you don’t have to record your voice using a very great audio processing software such as GarageBand or Audacity and then manually uploading them to the cloud using ftp or scp (Windows people, please proceed and read the UNIX/Linux manual).

I know those steps are simple but I think we can handover the uploading process to the computer and let that machine do that for us. After all, our wish is their command. So I remember about the audio specification in HTML5 and decide to play with it. (By the way, I’m thinking of using Flash too, but I think you’ve already knew my answer. In fact, at the end of this article, I still leverage Flash ability to get the things done). Continue reading

2013, Year of Evolved Technology

You guess, yet another predictions for this year. 2013.

2012 was a very entertaining year if we talked about mobile. Android and iPhone are always side by side, one overtook another, to lead the market with their innovation and simplicity (and a ‘little’ fight on patent litigation). Nokia is not the number one anymore but they’re struggling to get the crown back by teaming up with Microsoft building Windows Phone on their Lumia series. BlackBerry considered no luck and very slow in launching their new shiny OS.

Almost every spotlight goes to mobile.

2013 is coming and this is the year where mobile become more and more adapted. A few players in mobile OS have been declaring them self to become ‘the next big thing’ in mobile field. Ubuntu, Tizen, Firefox OS and a few customized-based-on-Android devices ranging  from automobile industry to home automation expected to be exists no longer from now.

So, what is it all about in 2013? For me, it’s the year full of customized technology. It’s the year where mobile get the most attention and biggest penetration all over the world. Hence, customized technology will be seen as a new ‘toy’ and startups will move to this area, sooner or later.

These are 4 things that, in my prediction, will be the superstar (for one) and upcoming superstar (for others) of 2013: Continue reading

Happy New Year!

I know, it’s been the 4th day of January 2013 and I’m just too late just to say “Happy New Year” but before you trash me with any kind of words, let me defend my self.

I didn’t remember the last time I updated my blog. I just saw it in and it said September 30, 2012. I felt it was a year ago since then, but I was wrong.

So, what’s up? (A few people who either subscribed or visited my blog regularly asked me what happened. Thanks guys, you’ve made me write again). Continue reading

The Distance using Haversine Formula

Over the last weekend, there’s a simple question running on my head:

“How can I compute the distance between two points on the earth?”

I’ve already knew, since in the university, how to compute the distance between two points in the plane. But I was wondering whether the formula was also work for the non-plane ellipsoidal shape like earth. So I’ve done a little search on the Internet and I found that the formula was a little bit different.

I’ve come across this great-circle distance and Haversine formula. Never heard about them before but the basic of the both, which is called trigonometry, was once familiar. So I did a little reading on these subjects (but I’m not going to proof the formula; hello, mathematicians *smile*) and figured out how I can make a better use of it. Continue reading

First Official Day!

I’m really excited to start my new role at U Connectivity Services as their new Chief Technology Officer. So many things to be read and so many things to be learned but these things are only make me feel more challenged.

I’m bursting with excitement.

Challenges Will Always Be Bigger than Us

I planned to move for the next (big) challenges and yesterday was my last day in the current employment. If some of you were questioning where was I in the last couple of months, I bet you’ve already knew it. Yes, I have worked at Lazada Indonesia (one of Rocket Internet’s fastest growing startup) and only took 3-months probation there before I decided to move on.

Here’s my last email to all employees regarding my resignation: Continue reading

Signing Off from Koprol

It’s been almost two years after I joined and “signed-up” with Yahoo! and assigned as one of the Koprol developers. I never thought that it would ended up this way but I believed that everything was happened for a reason. The truth is, there are lots of reasons.

I am a proud developer when the product I’ve contributed in was used by almost two millions of people, mostly young people. I also proud that my fellow developers always embrace new technologies, new possibilities and new techniques along the way we built the product. I am a proud developer when many users gave us feedback about how the Koprol for Android app should behave. Continue reading

HTTP Methods Every Web Developer Must Know

I’ve been programming web for years and I saw a lot of so-called web programmers doing web programming in their own preferred language. Most of them I’ve known were using PHP while a small group of them use Ruby and Python. But the languages doesn’t make any differences when it comes to HTTP Method.

A few weeks ago, I’ve worked with someone who really has expertise in PHP and has doing PHP for 6 years, give or take. I really love working with him as his knowledge about PHP overtakes mine and I do love to learn from him. One thing that I missed about was when he was using the wrong method for particular HTTP requests. He used GET where he should used POST, recklessly using (again!) GET instead of DELETE. But when I asked him about whether he was understand in what he’s doing, he answered, “it works. From the first day I learn PHP, it still works.”

I don’t want to judge him and throw all the mistakes on everything he read but this is dangerous as he will, in the future, be working with a beginner programmer in pair-programming. He could mistakenly put the wrong concepts and mix things up between GET, POST, PUT and DELETE (and another not-so-famous method in HTTP).

Trying so hard to remember all HTTP methods (and all their purposes) is just as hard as writing “Hello World” in Java without using an IDE for beginners. If you’re a web veteran and can spell all HTTP methods without thinking then you should not wasting your time reading this. Go get your things done. To those who are still confused and don’t care before about those methods, go read ahead. Continue reading