We recently revamped our developer guides to make them more user-friendly. The information for each service has been broken into its component parts, to make each feature more comprehensible. In this article, we share some of the changes we have made and they help you get the most from our products.

1. A new, easy-to-navigate landing page

Our new landing pages now have a developer guide map (our US Address Validation product is a good example) to provide easy access to each web service’s component parts. By clicking on the links on this page, you will be taken directly to the respective page that provides a more in-depth breakdown of the service’s individual fields. Below is an example of one of these landing pages.

2. Quick lookup & Open API

Our quick lookup page has been greatly simplified to provide only the most relevant data at your fingertips. Once you have received a trial or production license key, the validation process is as simple as plugging your input data into the fields, adding your license key, and clicking Execute. The web service request is made for you and the response formatted in the output section.

Similarly, if you are looking to run a different operation the Service Reference page has quick lookups for every operation within its respective service.  Check out an example of Address Validation US.

3. Citations and Additional Field Information

Have questions about the service fields? Need more information about how to leverage them to fit your business needs? Our redesign now includes accordion panels that can be expanded to provide more information about the field. We’ve also added citations next to some of the inputs and outputs where we have additional information available. In the example, below the Barcode Digits is linked to the following blog:

https://www.serviceobjects.com/blog/address-deduplication-using-usps-barcodes/

By clicking a reference link, you can read a more in-depth analysis of the field and often gain ideas about how to use the data point in your workflow.

Each of these new features is designed to help you get up and running more quickly with our services, and serve as an easy-to-use reference for your development work. Try out our new developer guide soon, and let us know what you think!

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.