choose json for building apis

2
SearchSOA.com Choose JSON for building APIs By null More and more, developers who are used to working in the Web and mobile worlds naturally turn to APIs as the most effective way to connect clients and servers, according to Greg Brail. As these developers encounter applicationtoapplication problems like businesstobusiness connections between enterprises, their first reaction is, "Why can't we just use an API here?" Brail answers that APIversusmiddleware question and compares APIbased integration to SOA and enterprise service busses (ESBs) approaches in this SearchSOA interview. He also offers advice on such API matters as change management, XML vs. JSON data formats and uses for hypermedia. Coauthor of the O'Reilly book, APIs: A Strategy Guide , Brail has a long history in middleware development. He built middleware libraries for Citibank and was principal architect for transact plus technical lead for BEA’s WebLogic JMS. At Apigee , an API and middleware backend as a service provider, he is the architecture lead for all products. When and why should APIs replace integration middleware? Greg Brail: Just as APIs are fast enough for the most demanding mobile applications, and secure enough for important consumerfocused use cases, there is no reason why they cannot be the default choice for integration tasks as well. There is very little reason to use a more traditional applicationtoapplication protocol or integration technology when an API can be used instead. Exceptions, I think, are fewer and farther between than people think. A good example would be applications like highfrequency financial trading, where the throughput and latency demands are so extreme that even TCP, let alone HTTP, is just too slow. Even where more typical enterprise technology like message queuing and publish/subscribe is used, in many cases, wrapping the messaging system with an API makes it easier to consume. How do APIs as an integration approach compare to SOA and ESBs? Brail: SOA is about connecting services within the enterprise to achieve reuse and save money. APIs build upon SOA by emphasizing developer usability and selfservice, and about creating new services that can be used both inside the enterprise as well as by customers, partners, and developers. SOA didn't do much to enable those kinds of use cases. ESBs solve part of the API integration and SOA problem, but APIs are a lot more. For instance, ESBs do nothing to make it easier for developers to consume APIs via selfservice, and they do nothing to make an existing system of record safe for mobile use on the Internet by managing hightraffic volumes and providing advanced security and threat detection. Our readers tell us that change management is a pain point in API management. What process and technical problems does it pose? Brail: An API is a contract between the API provider and the developer. Any contract has to clearly state what might change and how the developer will know about those changes. In the most common API style the URI and verbbased style that most developers understand it's generally understood that once a particular URI/verb combination is out there, it won't go away without a lot of notice, or change in an incompatible way. The key to making this contract work is good testing. Today we have tools like Swagger that let us formally specify the format of an API, and there are more and more tools appearing on the market that can use that data to test and verify an API. Without continuous testing of the API implementation, it's hard to guarantee that the contract remains valid. What are best practices, criteria and consequences of errors in choosing data formats (XML, JSON, etc.) when designing and building APIs ? Brail: Today, I think it's hard to go wrong with JSON. It's the easiest format to create and parse in nearly any language because it is so close to what most programming languages expect, parsing is reasonably fast, and it's readable enough. I think that 95% of APIs should just stick with JSON. The other 5%, in mind, breaks down into use cases where extreme performance is needed, and use cases where there are existing XML schemas that represent a lot of intellectual capital that you want to reuse. For extreme performance, see again highspeed trading. I'm talking about extreme performance, not a mere few thousand of tens of thousands of API calls per second. For existing XML schemas, see standards like FpML [Financial Products Markup Language] and the like where a lot of people spend a lot of time trying to create a common way to describe some very complex things in XML.

Upload: lalatendurath5716

Post on 07-Sep-2015

230 views

Category:

Documents


0 download

DESCRIPTION

d

TRANSCRIPT

  • SearchSOA.com

    ChooseJSONforbuildingAPIs

    Bynull

    Moreandmore,developerswhoareusedtoworkingintheWebandmobileworldsnaturallyturntoAPIsasthemosteffectivewaytoconnectclientsandservers,accordingto

    GregBrail.Asthesedevelopersencounterapplicationtoapplicationproblemslikebusinesstobusinessconnectionsbetweenenterprises,theirfirstreactionis,"Whycan'twejustuseanAPIhere?"

    BrailanswersthatAPIversusmiddlewarequestionandcomparesAPIbasedintegrationtoSOAandenterpriseservicebusses(ESBs)approachesinthisSearchSOAinterview.HealsooffersadviceonsuchAPImattersaschangemanagement,XMLvs.JSONdataformatsandusesforhypermedia.

    CoauthoroftheO'Reillybook,APIs:AStrategyGuide,Brailhasalonghistoryinmiddlewaredevelopment.HebuiltmiddlewarelibrariesforCitibankandwasprincipalarchitectfortransactplustechnicalleadforBEAsWebLogicJMS.AtApigee,anAPIandmiddlewarebackendasaserviceprovider,heisthearchitectureleadforallproducts.

    WhenandwhyshouldAPIsreplaceintegrationmiddleware?

    GregBrail:JustasAPIsarefastenoughforthemostdemandingmobileapplications,andsecureenoughforimportantconsumerfocusedusecases,thereisnoreasonwhytheycannotbethedefaultchoiceforintegrationtasksaswell.ThereisverylittlereasontouseamoretraditionalapplicationtoapplicationprotocolorintegrationtechnologywhenanAPIcanbeusedinstead.

    Exceptions,Ithink,arefewerandfartherbetweenthanpeoplethink.Agoodexamplewouldbeapplicationslikehighfrequencyfinancialtrading,wherethethroughputandlatencydemandsaresoextremethatevenTCP,letaloneHTTP,isjusttooslow.

    Evenwheremoretypicalenterprisetechnologylikemessagequeuingandpublish/subscribeisused,inmanycases,wrappingthemessagingsystemwithanAPImakesiteasiertoconsume.

    HowdoAPIsasanintegrationapproachcomparetoSOAandESBs?Brail:SOAisaboutconnectingserviceswithintheenterprisetoachievereuseandsavemoney.APIsbuilduponSOAbyemphasizingdeveloperusabilityandselfservice,andaboutcreatingnewservicesthatcanbeusedbothinsidetheenterpriseaswellasbycustomers,partners,anddevelopers.SOAdidn'tdomuchtoenablethosekindsofusecases.

    ESBssolvepartoftheAPIintegrationandSOAproblem,butAPIsarealotmore.Forinstance,ESBsdonothingtomakeiteasierfordeveloperstoconsumeAPIsviaselfservice,andtheydonothingtomakeanexistingsystemofrecordsafeformobileuseontheInternetbymanaginghightrafficvolumesandprovidingadvancedsecurityandthreatdetection.

    OurreaderstellusthatchangemanagementisapainpointinAPImanagement.Whatprocessandtechnicalproblemsdoesitpose?

    Brail:AnAPIisacontractbetweentheAPIproviderandthedeveloper.Anycontracthastoclearlystatewhatmightchangeandhowthedeveloperwillknowaboutthosechanges.InthemostcommonAPIstyletheURIandverbbasedstylethatmostdevelopersunderstandit'sgenerallyunderstoodthatonceaparticularURI/verbcombinationisoutthere,itwon'tgoawaywithoutalotofnotice,orchangeinanincompatibleway.

    Thekeytomakingthiscontractworkisgoodtesting.TodaywehavetoolslikeSwaggerthatletusformallyspecifytheformatofanAPI,andtherearemoreandmoretoolsappearingonthemarketthatcanusethatdatatotestandverifyanAPI.WithoutcontinuoustestingoftheAPIimplementation,it'shardtoguaranteethatthecontractremainsvalid.

    Whatarebestpractices,criteriaandconsequencesoferrorsinchoosingdataformats(XML,JSON,etc.)whendesigningandbuildingAPIs?Brail:Today,Ithinkit'shardtogowrongwithJSON.It'stheeasiestformattocreateandparseinnearlyanylanguagebecauseitissoclosetowhatmostprogramminglanguagesexpect,parsingisreasonablyfast,andit'sreadableenough.Ithinkthat95%ofAPIsshouldjuststickwithJSON.

    Theother5%,inmind,breaksdownintousecaseswhereextremeperformanceisneeded,andusecaseswherethereareexistingXMLschemasthatrepresentalotofintellectualcapitalthatyouwanttoreuse.Forextremeperformance,seeagainhighspeedtrading.I'mtalkingaboutextremeperformance,notamerefewthousandoftensofthousandsofAPIcallspersecond.ForexistingXMLschemas,seestandardslikeFpML[FinancialProductsMarkupLanguage]andthelikewherealotofpeoplespendalotoftimetryingtocreateacommonwaytodescribesomeverycomplexthingsinXML.

    http://searchwindevelopment.techtarget.com/definition/JSON-Javascript-Object-Notationhttps://apigee.com/about/http://shop.oreilly.com/product/0636920021223.dohttp://searchexchange.techtarget.com/definition/application-program-interfacehttp://searchsoa.techtarget.com/definition/enterprise-service-bushttp://searchsoa.techtarget.com/definition/XMLhttp://searchcio.techtarget.com/definition/change-managementhttp://whatis.techtarget.com/definition/FpML-Financial-Products-Markup-Languagehttp://searchsoa.techtarget.com/definition/service-oriented-architecturehttp://searchsoa.techtarget.com/tip/API-design-How-to-properly-build-an-application-program-interface
  • WhatapproachesshoulddevelopersandarchitectstaketodesignAPIsthataremoreusabletodayandviableinthefuture?Brail:Therearesomeplaceswherehypermedia[whichextendshypertextlinkingtoincludelinksamonganysetofmultimediaobjects]isveryeffective.IftheAPIproviderandthedevelopersunderstandeachotherwell,andagreeonaconventionandcontract,thenahypermediadrivenAPIcanbethebasisforarobustandefficientuserexperienceonethatallowstheAPIprovidertoadjustontheflytochangingnetworkandmarketconditions,inthesamewaythatatraditionalWebappcanbechangedbasedonuseranalytics.Idon'tthinkwe'llseehypermediabasedAPIsreplacetheideaofaverywelldescribedURIpatternforeverythingintheworld,butittheybecomeaveryeffectivewaytowritemobileapps.

    Finally,IthinkthattheideaofmakingamoretraditionalAPI"navigable"byaddinghypermedialinksthatletaclientbrowsetheAPIjustasaWebuserbrowsesawebpage,issomethingthatalotmoreAPIsshouldbedoingtoday.

    30Jun2015

    AllRightsReserved,Copyright20012015,TechTarget|ReadourPrivacyStatement

    http://searchsoa.techtarget.com/about/copyrighthttp://www.techtarget.com/html/privacy_policy.htmlhttp://searchsoa.techtarget.com/definition/hypermedia