Welcome!

Java IoT Authors: Zakia Bouachraoui, William Schmarzo, Liz McMillan, Pat Romanski, Elizabeth White

Related Topics: @DevOpsSummit, Java IoT, @CloudExpo

@DevOpsSummit: Blog Feed Post

My Love/Hate Relationship with APIs | @DevOpsSummit #API #DevOps #Microservices

If you're creating an API, don't chase buzzwords - help your partners solve problems

My Love/Hate Relationship with APIs
by Matt Heusser

Ten years ago I was a programmer working at an insurance company. The hard IT work of an insurance company is claims processing - taking in new members, getting claims, figuring out how they should be payed, and paying them electronically. That meant a big database.

We wrote a lot of SQL, the programming language for databases. When our claims processing vendor came in telling us about Service Oriented Architecture, we yawned. Instead of a hand-rolled SELECT statement, something like this:

SELECT member_id FROM members where first_name="John" AND last_name="Smith" AND birthdate = "1/1/1990″;

We instead would have to code something like this:

<Query type="select" table="members" where_ first_name="John" where_last_name="Smith" where_birthdate="1/1/1990″>

From what I could tell, the middleware would take the XML, make my original SQL query, call the database and return the same results. So a more complex implementation that takes more processing for the same results. I was not impressed.

Today I see that first introduction as a terrible one - a vendor chasing a buzzword, not a real problem to solve. And I do see API's solving some problems - and creating others. The question is which problem you'd rather have. So this is the rest of my story.

Entering Socialtext
From the insurance company I went to Socialtext, making web-based, collaborative software from home for a Silicon Valley Started funded by Draper Fisher Jurvetson, who also funded Twitter, Skype, Yammer, SpaceX, and Tesla Motors.

Talk about your culture shock. The biggest technical difference I noticed between Socialtext and the insurance company was the architecture. Major business functions, like search, adding or deleting a tag from a page or profile, search, and get text for a page were all driven by REST APIs. Once authenticated, you could calculate the URL, pass it in like a web page, and get JSON back. The read-only pages didn't even require authentication, so you could type:

http://www.socialtext.net/data/workspaces/help-en/pages/Searching?accept=json

Right into the browser, hit return, and see the raw text. Go ahead, try it yourself. The accept=json bit gives a format, JSON, that is easy for computers to read into an object. Drop it for a more traditional HTML rendering.

After I checked the results by hand, I could save them in a text file, then write a tiny bit of code to hit the web service and compare it to the expected results.

Adding authentication is trivial; here's a simple python example using a library called requests:

r = requests.get(‘https://www.socialtext.net/data/workspaces/software-delivery-24-7/pages/scrum_for_testers?accept=json', auth=(‘[email protected]', ‘mypassword') )

print r.status_code

print r.text

We ended up writing code libraries to make this even easier. The typical pattern was load up a known workspace and check the read qualities, but also to perform logical operations. So, for example, search for users tagged ‘Smartbear', do not see Matt Heusser, add tag Smartbear to Matt, search again, see Matt, delete tag, search again, do not see Matt listed and so on. Exercising the API was incredibly fast, easy, and allowed us to figure out if the problem was in the graphical front-end or the back end very quickly.

That was all good, until about a year past, and suddenly users asked us for mobile and desktop versions of our software . This was back when a "mobile version" of a website meant a total rewrite.  I braced for the worst.

Reskinning the Interface
Most of the work in building an application is on the back end; prototyping the user interface is the easy part. By having a solid API, we had actually turned the back-end as a reusable component. The developers at Socialtext had a real-only version of the mobile website up in week, and a major buildout of functionality in two sprints - four weeks. Audrey Tang took one large piece of functionality, called Socialtext Signals, which was sort of for-inside-a-company-only version of twitter, and wrote an Adobe Air Application in three days! The teams also yanked functionality out of the web-based application, from workspaces to profiles to signals to display a page, and put them on "widgets" they you could drag and drop for form your own personal dashboard.

Here's four examples of signals, on a phone, as a webpage, in a desktop application, and on a dashboard.

signals_mobile

signals_webpage

signals_widget

socialtext_signals_desktop

At the previous companies I had worked with, each of these would have been a new project, if not an entirely new team, to build new, redundant technology, to essentially do the same thing.

When Matt met SOFEA
After Socialtext, I went to work with a large wholesale company doing an ambitious ecommerce project, instead of listing their products on a partner site. The team used something I hadn't heard of called a SOFEA, which stands for Service Oriented Front End Architecture.

With SOFEA, there is no back end; no java, no C#, no PHP or ASP.NET. Instead the application serves up static web pages that contain javascript. The Javascript makes API calls to the back-end - login, search, production description, add to cart, and so on. The Javascript takes the result and creates HTML - for example, looping through a list of search results to show products that contain "chicken wings."

We could us the developer toolbar to see exactly what values pass over the wireless - what queries were made, what the results were, and how long they took.

The eCommerce project was split into two groups, with front-end developers and back end. This allowed people to specialize in one area or the other, which made it easier to hire.

Matt added the tag "testing tagging" to a Socialtext page; then the software made calls to re-order the tags alphabetically and redisplay.

developer_toolbar

That also had drawbacks. The front-end typically a sprint ahead of the web services, so we would test a User interface that didn't do anything yet - and often could not release because the front-end for a feature was done but the back-end was not. This made us lose the customer perspective of one feature, instead thinking in "feature halves." Also, if a tester filed a bug, and didn't indicate where the problem was, it would be bounced back.

Neither of those are really API problems, and they are solvable. We could have hid non-active UI elements with config flags turned off, and paired front-end and back-end developers to run a story end-to-end. Still, it didn't excite me.

It was during the ecommerce project that I first really got to use SOAPUI, as a sort of non-code version of the python I mentioned above. SOAPUI could store and handle login credentials, could keep a list of URLs and expected results as a "test suite", but best of all, it allowed me to experiment with different input values quickly, by changing the URL, looking at well-formatted results (JSON can be hard to read), taking what I learned and trying something else.

The Third Time May Not Be The Charm
On the next big project, we had grown over years. One of the features was a small API, but the entire application was designed as a network, where anyone could meet anyone and develop a business relationship. That meant the whole application was one big database. The Development and Test databases were Terrabytes in size, and no, it was not possible to have a copy of the database, even a tiny one, for your own personal use. That meant stale data, shared user accounts, and  no easy way to make setup/test/teardown happen.

We could have set up some sort of service virtualization - to simulate the API with known, canned results, to test applications that used the API - but the API itself was extremely brittle. My lesson was that a good API by itself my night be enough to make a project sing.

One More Time, with Flair
At the insurance company the real problem wasn't figuring out a member id; it was figuring out if a member had coverage at a specific time. After far too long hand-rolling the same type of lookup over and over again, I wrote a bit of code to figure that out for me and put it in a code library. That's an API of sorts, and it did lead to code re-use. If the software vendor had only done that - enabling real business processes, not just wrapping table lookups in XML ... I might not have been so opposed to it in the first place.

So if you're creating an API, don't chase buzzwords - help your partners solve problems. If you a technical person pushed to use an API, but don't see the value, that's okay. Despite all the pressure, they aren't going to pick up a keyboard and write the code. They need you.

You get to do what makes sense.

Read the original blog entry...

More Stories By SmartBear Blog

As the leader in software quality tools for the connected world, SmartBear supports more than two million software professionals and over 25,000 organizations in 90 countries that use its products to build and deliver the world’s greatest applications. With today’s applications deploying on mobile, Web, desktop, Internet of Things (IoT) or even embedded computing platforms, the connected nature of these applications through public and private APIs presents a unique set of challenges for developers, testers and operations teams. SmartBear's software quality tools assist with code review, functional and load testing, API readiness as well as performance monitoring of these modern applications.

IoT & Smart Cities Stories
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...