Welcome!

Java IoT Authors: Yeshim Deniz, Pat Romanski, Liz McMillan, Zakia Bouachraoui, Carmen Gonzalez

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
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
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...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
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...
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...