Third Party API Traps: How You Can Avoid Them

THIRD PARTY-APIS

“For con­sumers, a bad API means a longer de­vel­op­ment cy­cle and a higher de­fect rate; and in some cases, even a skills prob­lem in the team” - Peter Hendriks, IT ar­chi­tect at Infosupport

Generally, de­vel­op­ers will pay close at­ten­tion to server side script­ing and may at times ne­glect the client side. When you load a web­site, your browser will stop the build of the page, check for any API’s, get the wid­get and then load the page. What this means is that if the client side script­ing is poor, it will in­crease the page load time. Users may in turn get frus­trated with your web­site’s lengthy load times, com­pro­mis­ing the ef­fec­tive­ness of the API.

Another com­monly made mis­take is fail­ing to watch for hang time. When the API soft­ware pulls in in­for­ma­tion, works off that, and pushes out data, the time it takes to build the re­quired out­put is called hang time. While it’s wait­ing to get the out­put it will not give you any re­sponse. As a re­sult, the data is not re­layed in an ef­fi­cient man­ner. Picture a movie you’re down­load­ing. In or­der to watch the movie, you would have to wait un­til the down­load is fin­ished. One so­lu­tion in PHP is the Object Flush, where you flush out your data, even be­fore you think you have the full re­sponse. As a re­sult, you can es­sen­tially watch the movie be­fore it’s fin­ished down­load­ing.

The next pit­fall con­cerns le­gal com­pli­ca­tions. Ideally, the third party API you’re us­ing should al­low you to legally use the data the way you want to use it. If there are re­stric­tions in place and you have to al­ter the API func­tion­al­ity or use it in an in­ef­fi­cient man­ner, de­ploy­ing the API may not be in your best in­ter­ests. That is where you con­duct a cost-ben­e­fit analy­sis to work out the ac­tual value of the third party API and whether it would be worth build­ing your own.

Vendor Mistakes

At times, soft­ware en­gi­neers can get caught up in the prob­lem and over­think it. Usually, the best APIs and the eas­i­est to im­ple­ment are the sim­plest. Trying to cre­ate a com­mon re­sponse for all APIs is un­wise. It cre­ates un­nec­es­sary com­pli­ca­tions. Getting user in­for­ma­tion is dif­fer­ent from get­ting a video in­for­ma­tion, which is dif­fer­ent from post­ing a com­ment, which is dif­fer­ent from get­ting a list of fol­low­ers.

Another im­por­tant con­sid­er­a­tion is en­sur­ing the URL’s are con­sis­tent. This can be com­pared to nam­ing con­ven­tion. Make sure the API’s URL stems and query string have a strong logic to it. For ex­am­ple, to get pro­files use api.work­ing­mouse.com/​pro­files.php, but to get im­ages use api.work­ing­mouse.com/​im­ages/​get.php. Thinking as “objects” and “actions” is a good start. It’s an­other way of sim­pli­fy­ing your API and en­hanc­ing the user ex­pe­ri­ence.

Image

Discover Software
Secrets

ABOUT THE AUTHOR

David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book a con­sul­ta­tion