Posts Tagged ‘API Implementation’

Our Top 5 Blog Posts of 2019

We love educating our clients. And we did quite a bit of it in 2019, with over 100 blog posts. Our blog, featuring informative articles and detailed user tips, is one of the most popular features of the Service Objects website. That is probably why you are reading this now!

We are also closing out a great year that includes the milestones of over 3 billion contact records validated since our 2001 founding, and over 2800 customers including industry leaders such as Amazon, Microsoft, Verizon, major credit card providers and many more. We are proud of 18 straight years of over 99% reliability, and even more proud of our commitment to the environment, ranging from saving nearly 200 million pounds of paper to supporting reforestation efforts in our native California.

As we wrap up this year, let’s take a look back the five of most popular of our fact-filled blog posts. Here are some of the articles that you found most useful in 2019:

Mailing Address vs Physical Address: What’s the Difference? Not every physical location is a valid postal address: in fact, in the United States, there are even cases where your mail is delivered from another state! Not to mention non-postal addresses used by shipping services, private mailboxes, and more. This detailed article by senior software engineer, Emanuel Fuentes, breaks this all down for you.

Reverse-Phone Look-Up: A Deep Dive. Telephone contact data has a great deal of associated data that can be important for applications ranging from TCPA compliance to marketing efforts. Our products can provide information about a phone number including carrier, porting status, line type, and user contact data. Jonas Shaefer, our Director of Engineering, walks you through the various options available.

A Brief Look at the Journey of an Email Message. Ask most people how an email message gets from point A to point B and they will probably have no idea. In reality, emails follow a multi-step process involving mail servers, communications protocols, subservices and much more. This post provides an overview of email delivery, and sheds light on many of the acronyms and processes involved in sending and receiving email messages.

Lead Scoring: How It Fits in with Marketing Automation. Marketing with a database full of bad leads is a little like believing you are rich because you still have more checks. In this article, our Director of Marketing, Carolyn Healey, provides a seasoned marketer’s perspective on how testing the data quality of your contact leads needs to be an essential part of every campaign.

Choosing a Web API: REST, Remote Procedural Call or Hybrid. No top 5 list of articles from Service Objects would be complete without giving credit to all the great technical information we provide to fellow programmers working with our products. This article goes into detail about the mechanics of making the API calls that are at the heart of implementing most Service Objects services.

Lots more good information will be coming your way from our team in 2020, and we truly enjoy sharing our knowledge and market perspectives with you, our customers and followers. We look forward to connecting with you from here, and want to wish all of you a happy holiday season and a prosperous new year.

API Security: A Closer Look

Recently, we published a blog article discussing the growth of the “API Economy”: a term coined to describe the proliferation of API-based tools being incorporated into many software products and applications. In this article, we discuss one of the side effects of this growth: the need for more data security as a result of the growth of API use.

Application programming interfaces, or APIs for short, have transformed the way we create and use software by linking your application to other people’s code and data. Our APIs, for example, can be integrated into your code, CRM or e-commerce platforms to do things like validate your contact data against most of the world’s addresses, provide sales tax data down to specific address levels, verify and correct lead information, to name a few – right in your app.

APIs have truly opened up the world for applications such as retail, sales and marketing automation and much more. However, APIs have the potential to introduce security risks, particularly if they represent a pipeline to your data assets. A recent example of an API breach involved Australia’s largest property valuation firm exposing the loan details for over 100,000 customers.

The security risks of APIs are generally well understood by the developer community and our internal team pays close attention to changes and developments in this space. Below are some of the main thoughts on API security and risk management.

Security and APIs – What the experts say:

In 2016 David Berlind, the editor-in-chief of ProgrammableWeb, a portal site and directory for API developers, gave testimony to a government healthcare IT task force on current issues in API security. Here are some of the key points he raised:

Security starts with access to APIs. One of the largest concerns with APIs nowadays involves who gets the keys to the candy store – particularly if an API facilitates access to sensitive data. Berlind describes this in terms of APIs targeted at “LSUDs” (large sets of unknown developers) versus “SSKDs” (small sets of known developers). Increasingly, many firms are restricting access to their APIs and documentation to known and verified partners.

Security standards are still a work in progress. While specific API providers maintain their own security standards – for example, PayPal requires API users who store credit card data to follow PCI compliance rules – Berlind also notes that even major players such as Google, Apple and Facebook have all fallen prey to API breaches, and security standards are continually evolving.

Contractual protections matter. While this won’t stop bad actors, putting language in an API’s terms of service (TOS) can be an important tool for enforcing the proper use of APIs among customers.

Third party certification is needed. Given that API security continues to evolve, in what Berlind calls a “cat and mouse” game between hackers and developers, he feels that there will ultimately need to be an industry-wide API security standard that is continually informed by what we learn from the latest security incidents.

Since this testimony, dialogue continues around the evolution API security, including this list of best practices such as front-end authorization and authentication, checking results data, and investing in proactive security testing. Much more remains to be done in this area, but at least this topic is at the forefront of the API developer community.

Our perspective on API security

Of course, we are API developers ourselves, so we are extremely sensitive to the issues of API security. Part of this springs from self-interest: for vendors like us, who handle sensitive personal data for what are often mission-critical applications, our business depends on it. But we are also observing the growth of the entire API ecosystem with interest, and this is a topic we all need to be talking about.

Our API products carry less risk because we do not store customer data. Instead, each record a customer submits to us is processed through a secure and encrypted connection, generally by validating it against one or more databases, and validation results are returned through a secure and encrypted connection. We neither store customer input nor resulting output, so there is little to “steal” by calling our APIs.

Personally, we feel that part of the solution is for API developers to adopt accepted best practices in data security, and document these procedures publicly – ours are here, for example. To create more customer confidence as APIs proliferate, our industry will increasingly need to take people inside the “black box” of API infrastructure and discuss what steps are being taken to protect their data. We are glad to be part of this dialogue, and will continue to be part of it in the future.

Tuning your Implementation: What Impacts Speed and Throughput

How fast is fast? How fast should things be? And more importantly, what can you control to make the response time of using our services as fast as possible?

In this blog we will break down the key components of response time, to shed some light on what you can optimize to make your implementation respond faster. Whether it is a call to a Service Objects web service or an API integration in general, there are specific phases that take place: input data preparation and transmission, data processing, and results transmission and processing. For example, a simplified view of a single data validation request is as follows:

  • Your data is securely sent to the Service Objects web server to be processed
  • The data is received by our server and processed/validated
  • The validated data is then securely returned to you

Most people think of response time as being the round-trip time to get your data validated – and this is indeed the primary concern – but total throughput should be addressed as well. And if you are able to get a single validation done as optimally as possible, expanding the workflow to fit simultaneous requests shouldn’t take too much modification to the workflow.

To understand what is going on under the hood – and in particular, understand what factors may be slowing down your speed – let’s compare this process to a trip to the grocery store. It has similar phases to a data validation process: you leave your house, travel down the road, stop at the market, purchase your groceries, and then drive home. Here is how this process breaks down:

Step 1: Data preparation. This is analogous to the steps you take before leaving your home. Did you turn off the lights? Are all of the doors shut? Is the security system armed? Do you have everything on your grocery list?

Each of these steps is similar to the checks that your application goes through in order to leave your company’s internal network. The application has to gather the information to be processed, dot all of the i’s, cross all the t’s, make sure it knows where it is going, and make it through any layers of security your company has in place. Each layer takes time to complete and detracts from your overall speed.

Step 2. Input data transmission. This is like traveling down the road to the supermarket. How much traffic people encounter depends on factors such as how many lanes the road has, how many people are in each car, and how many cars are on the road. From an engineer’s perspective, this is like the concept of single threading and multithreading: if the road that you are traveling down has multiple lanes, the number of cars (e.g. API requests) can be larger before running into traffic.

By creating a multithreaded application, you can effectively widen the road and allow for more throughputs. Your choices include single car + single lane (single value request), single car with multiple people in it + single lane (smartly using one validation client to do multiple requests), multiple cars with single passengers on multiple lanes (semi-smart multithreaded validations), and multiple cars with multiple passengers on multiple lanes (really smart multithreaded apps).

Step 3. Data processing. Once you reach the store and make your purchases, it is time to pick a checkout aisle. The number of aisles that are open act similarly to the lanes on the road. More aisles allow a larger number of people to be processed before a queue builds up.

This part of the process is handed by Service Objects. We have spent the last 15+ years not only making sure to stock our shelves with the best quality products, but also ensuring that there are enough checkout aisles to meet the needs of our customers. In our case, we have multiple data centers (super markets) with load balanced web servers (smartly managed checkout aisles) to keep all of our transactions moving through smoothly.

Step 4. Results data transmission. The return trip from the super market is very much the same as the trip there, but in reverse order. Similarly, entering your house with the newly purchased items (validated data) is the same in the opposite direction. This stage also contributes to the round trip time required to process a request.

Step 5. Unpacking the results. When you return from the store, you still have to unpack your groceries. Likewise, once you get the data back from the service, you still need code and business logic to unpack the results and store them in a form that meets your needs. (Or, to extend our analogy further, create a delicious meal from the quality ingredients that Service Objects supplies you!)

So total processing time is a careful balance of getting through your front door, navigating down the single or multi lane highway, checking out with your groceries, and then making the return trip home. From an API-call perspective, improvements to your speed start with your network, smart choices when writing your integration code, and juggling the requirements put in place by your business logic. And if you are looking to increase your throughput, a multithreaded application or distributed system will often increase your capacity.

Finally, one more analogy (we promise!). Good grocery stores have staff who can help you make the most of your shopping trip. Likewise, Service Objects has an industry-leading team of technical support experts who know their stuff, and are always happy to help you make the most of your implementation. How can we help you? Contact us any time to discuss your own specific needs.