If you want to create a web service today, you have tons of technologies from which to choose.
Back in the day, the variety of programming languages, frameworks, databases and front end solutions was not so impressive. Most websites and services ran on a PHP/MySQL tandem. A substantial number of sites still do. Back to back with a world of modern frameworks (Ruby’s ROR, Python’s Django and Pylons, etc.) and new solutions such as NodeJS, there still exists the internet of old technologies.
And if your customers still use these, you need to take that into consideration.
Why not just modernize?
When you create something from scratch, it’s easy to choose the right framework — well, right at the time of creation, that is. But when you started your business back in 2002 using the solutions you had at hand then, it’s not so easy to change. A lot of time, money and effort has been invested, a complex structure has been built and now you know that if you were to modernize just a single element, you would have to change the whole thing. Or it would take ages.
This may sound unbelievable as rewriting and modernizing isn’t anything uncommon. Let’s look at this from a different perspective, and liken the technology to design. We all want beautiful products and great user experience and yet we still use ugly websites every day!
Let’s face it, even some giants like Amazon don’t have websites that follow current hot trends. Yes, Amazon puts a great deal of thought into the design of their websites (they have to increase conversions, etc.), but that’s a different matter. There are many reasons for Amazon to make only small changes – one of them is that people are used to their sites and know how to buy there.
The Devil and the Deep Blue Sea
If your customers use old-time solutions and you need to integrate with them, you know that sooner or later you won’t be able to keep up the high level of service. When you run on prehistoric technologies and your customers are world-changing startups, you know you may be out of business soon.
It’s not an easy situation to face: you either support non-modernized solutions and risk not getting any new customers or you change your ways and force the old customers to update.
To REST or Not to REST
One of companies that had such a dilemma was PayLane. We could distinguish between relatively new and small companies/services that usually use (and require!) modern technologies, and older companies: a fair number of big corporations with large systems that remember the old days. Of course, there are also some lonely riders who just don’t follow trends, but that’s a rather negligible number.
Such variety results in completely different approaches and communication. For example RESTful APIs are considered a standard approach nowadays, yet many of PayLane’s clients still wanted to use SOAP. Yes, these were the “olds chool” ones who had used PHP and SOAP for years, before REST was popularized.
So, the company stayed with a SOAP API, because it was what many of our clients felt better with. It wasn’t a simple choice, because many other naturally preferred REST and the company understood this. PayLane actually had a RESTful API working for some time and offered it to those who preferred it (for example, mobile developers – PayLane felt that it was simply inappropriate not to do so).
PayLane had clients who wanted to implement their payment systems using PHP, Python or Ruby, we had some who preferred Java or C#, but we also had more surprising cases, for example Lisp! There were lots of other differences, even small ones. For example, some clients (usually big companies) wanted technical documentation in a doc or a PDF file, they didn’t consider websites constituted proper documentation. This was the complete opposite of what startups expected.
For some time PayLane simply counted the numbers and those numbers were convincing us to stay a little longer with the SOAP API. Revolutions usually cost companies a number of clients, but they’re reasonable only if the benefits overcome such loss. PayLane decided to go with small steps.
One Step at a Time
PayLane maintained two API versions for some time, but finally we reached a point where we could switch the situation. The company managed to convince a great number of our clients to REST and get even more new ones, so there was no more need to double the work with the APIs.
The RESTful API became the official one, PayLane adjusted our Developer Zone (including documentation) and released a free whitepaper on REST to make things easier for clients or anyone who is interested in the subject.
The old SOAP API still works, but PayLane considers it deprecated and encourages everyone to use the RESTful one.
Trends are important and usually don’t come out of nothing. It’s important to keep up with the latest technologies to offer customers the best service, and thereby remain competitive.
It’s equally important to make your customers feel comfortable with how you work with them. If you keep changing the ground rules, you may be deemed unstable or unreliable – even though you’re trying to improve your service to your customers.
PayLane worked hard to make the transition to a better technology smooth for their clients, finding a balanced approach that met the needs of both those who were eager to adopt new technology and those who wanted the stability of what they already knew.
We found an incremental, gradual approach supported by clear information and supporting customer choice was worth the effort of maintaining duplicate systems for a time. Others may find an approach based on revolutionary change to be more effective than one based on evolution.
What’s been your experience?
Ula Lachowicz
