fig1 illustrates an exemplary client - server system 100 in which embodiments may operate . the client server system 100 includes a client device 110 and a server device 150 that are in communication with each other over a network 160 . for simplicity of illustration , the illustrated client - server system 100 is shown to include a single client device 110 and a single server device 150 . the system 100 may of course include a different number of client devices or server devices . the client device 110 and the server device 150 may be implemented by any suitable computing device , such as computing device 800 ( to be discussed below in connection with fig8 ). the illustrated server device 150 includes an api infrastructure 152 , which includes several apis . in particular , the api infrastructure 152 includes a url shortener api 152 a , a location api 152 b , and other apis 152 c . the apis 152 a - 152 c are shown as examples , and the api infrastructure 152 can have fewer , different , or additional apis . the server device 150 stores a directory entry repository 154 . the illustrated directory entry repository 154 includes a directory entry 154 a that corresponds to the url shortener api 152 a , a directory entry 154 b that corresponds to the location api 152 b , and directory entries 154 c that correspond to the other apis 152 c . the server device 150 also stores a discovery document repository 156 . the discovery document repository 156 includes a discovery document 156 a that corresponds to the url shortener api 152 a , a discovery document 156 b that corresponds to the location api 152 b , and discovery documents 156 c that correspond to the other apis 152 c . the format and contents of the directory entries 154 a - 154 c and the discovery documents 156 a - 156 c are discussed in greater detail below in connection with fig2 and 3 . the server device 150 includes an apis discovery service 158 . the apis discovery service 158 is configured to access metadata in connection with the api infrastructure 152 to provide information about configurations of the apis 152 a - 152 c . this information is stored to the directory entry repository 154 and the discovery document repository 156 . various clients can access this information from the directory entry repository 154 and the discovery document repository 156 . for example , the api client 118 can access information about configurations of the apis 152 a - 152 c by using retrieval unit 112 and directory data searching unit 116 . with continued reference to fig1 , the illustrated client device 110 includes a retrieval unit 112 , a library building unit 114 , a directory data searching unit 116 , and an api client 118 that can communicate with the server device 150 via a network interface 120 . the retrieval unit 112 operates in conjunction with the directory data searching unit 116 to retrieve information from the directory entry repository 154 and the discovery document repository 156 in the server device 150 . the library building unit 114 can produce client libraries based on the discovery documents 152 a - 152 c . as mentioned , the illustrated client device 110 and the server device 150 communicate with each other over the network 160 . the network 160 can be the internet , a local area network , mobile phone network , or any other network of machines with which the client - server system 100 exchanges data . fig2 illustrates an exemplary listing 200 of a directory entry according to an embodiment . the directory entry listing 200 shows a format of the directory entries 154 a - 154 c ( illustrated in fig1 ) according to an embodiment . in other embodiments , the directory entries 154 a - 154 c can have a different format . the illustrated directory entry listing 200 includes several fields , including a name 202 , a version 204 , a title 206 , a description 208 , a link 210 to a discovery document , a link 212 to an icon , a link 214 to documentation , labels 216 , and preferred status 218 . the directory entry listing 200 can include fewer , more , or different fields than those shown . fig3 illustrates an exemplary listing 300 of a discovery document according to an embodiment . the discovery document listing 300 represents the format of each of the discovery documents 156 a - 156 c ( illustrated in fig1 ) according to an embodiment . in other embodiments , the discovery documents 156 a - 156 can have a different format . the illustrated discovery document listing 300 includes several fields , including directory information 302 , a path 304 to an api root , authentication details 306 , a listing 308 of schemas for all api requests and responses , a listing 310 of top - level methods in the api , a list 312 of all api resources and methods available on those resources , additional information 314 about each method , and a listing 316 of specialized api features . the discovery document listing 300 can include fewer , more , or different fields than those shown . in an embodiment , the directory entries 154 a - 154 c and the discovery documents 156 a - 156 c are formatted in the json ( javascript object notation ) language . although an embodiment uses json , other embodiments can use other machine - readable languages , such as , for example , xml ( extensible markup language ). the following section discloses json - formatted examples of a directory entry and a discovery document . json provides a simple way to represent arbitrary data structures . json uses a text format that is language - independent and uses conventions that are familiar to programmers of c , c ++, c #, java , javascript , perl , python , and others . rfc 4627 defines the json format . fig4 illustrates a json representation of the directory entry 154 a illustrated in fig1 , according to an embodiment . with reference to fig1 and 4 , the directory entry 154 a includes metadata in connection with the url shortener api 152 a . the json representation of the directory entry 154 a shown in fig4 is a portion of a larger document called an api directory . the api directory includes not only the directory entry 154 a corresponding to the url shortener api 152 a , but also directory entries corresponding to other apis ( for example , the directory entries 154 b and 154 c ). to provide clarity , the other directory entries have been omitted from the illustration in fig4 . although an embodiment provides an api directory that includes multiple directory entries , in another embodiment , each directory entry constitutes its own document . with reference to fig1 , in an embodiment , the retrieval unit 112 can access the directory entry 154 a by executing the following unauthenticated http get request : “ get https :// www . googleapis . com / discovery / v1 / apis ”. in response to the get request , the retrieval unit 112 receives the json - representation of the api directory that includes the directory entry 154 a . as mentioned above , fig4 illustrates the json representation of the directory entry 154 a , which includes information about the url shortener api 152 a . in fig4 , line numbers have been provided to aid in explaining the contents of the json directory entry 154 a . with reference to fig4 , the directory entry 154 a includes several types of information about the url shortener api 152 a . these information types include identification information ( lines 8 - 11 ), discovery information ( line 12 ), documentation information ( lines 13 - 17 ), and status information ( lines 18 - 21 ). the identification information includes a name “ url shortener ” ( line 8 ), a version “ v1 ” ( line 9 ), a title “ url shortener api ” ( line 10 ), and a description “ lets you create , inspect , and manage goo . gl short urls ” ( line 11 ). the discovery information is a discovery document link “./ apis / urlshortener / v1 / rest ” ( line 12 ). this link is a relative uri ( uniform resource identifier ) that provides access to the discovery document 156 a ( shown in fig1 ) that corresponds to the directory entry 154 a . the documentation information includes a link to icons ( lines 13 - 16 ) that correspond to the url shortener api 152 a and a link to documentation ( line 17 ) that explains aspects of the url shortener api 152 a . the status information of the directory entry 154 a includes labels and preferred fields ( lines 18 - 21 ). this section explores the format of an exemplary discovery document in greater detail . the example discussed below refers to the url shortener api 152 a . the syntax used in this example is purely for illustrative purposes , and embodiments are not limited to this syntax . the following discussion is meant to provide a general overview of the sections of the discovery document that are relevant to this disclosure . the discovery document begins with a set of api - specific properties , as follows : these properties include details about the url shortener api 152 a . notably , the “ basepath ” field indicates the path prefix for this particular api version . in an embodiment , the operation of an api acts on data objects called resources . the discovery document is built on the concept of resources . the discovery document has a top - level resources section that groups all the resources associated with the api . for example , the url shortener api has a “ url ” resource . inside each resource section are the methods associated with that resource . for example , in a json embodiment , the url shortener api 152 a has three methods associated with the url resource : “ get ”, “ list ”, and “ insert ”. the discovery document also includes schema information . a schema describes what the resources in an api look like . the discovery document has a top - level schema section , which contains a name - value pair of schema id to object . schema ids are unique for each api and are used to uniquely identify the schema in the methods section of the discovery document . the discovery document is built around methods . methods are operations that can be performed on an api and are included in the discovery document . the methods section may be found in various areas of the discovery document , including at the top level ( api - level methods ) or at the resources level ( resource - level methods ). the following is a json - formatted example of the “ get ” method : this method contains general details such as a unique “ id ” to identify the method , the “ httpmethod ” to use , and the “ path ” of the method . if a method has a request or response body , these are documented in the discovery document . for example , in the “ get ” method above , the “ response ” syntax indicates that the response body is defined by a json schema with an id of “ url ”. this schema can be found in the top - level schemas section of the discovery document . both request and response bodies can use the “$ ref ” syntax for referring to schemas . if a method has parameters that are to be specified by a user , the discovery document documents these parameters in a method - level parameters section . this section can contain a key - value mapping of the parameter name to further details of that parameter . for example , the following json code is a parameter section : in this example , there are two parameters for the “ get ” method : shorturl and projection . a parameter can go in either the path or the url query ; the location property indicates where the client library should put the parameters . fig5 illustrates an exemplary method for building a client library according to an embodiment . the method begins at stage 500 . at stage 502 , a client device receives a discovery document that is formatted in a first machine - readable language . the discovery document includes information that describes resources of a first api of a server device . for example , with reference to the embodiment illustrated in fig1 , the retrieval unit 112 of the client device 110 retrieves the discovery document 156 a from the discovery document repository 156 of the server device 150 . in an embodiment , the discovery document 156 a is formatted in json . as mentioned , the discovery document 156 a includes information that describes resources of the url shortener api 152 a . at stage 504 , the client device executes instructions that are formatted in a second machine - readable language . this generates a library that includes instructions that are formatted in a second machine - readable language . the library enables the client device to interface with the api of the server device . for example , with reference to the embodiment illustrated in fig1 , the library building unit 114 generates a library that enables the api client 118 of the client device 110 to interface with one of the apis 152 a - 152 c of the server device 150 . the method of fig5 ends at stage 506 . fig6 illustrates a general method for carrying out stage 504 of fig5 , according to an embodiment . the method of fig6 begins at stage 600 . stage 602 involves generating an empty client library . for example , with reference to the embodiment illustrated in fig1 , the library building unit 114 generates an empty client library . stage 604 involves parsing the discovery document to locate resource descriptors . for example , the library building unit 114 can parse the discovery document 156 a to identify resource descriptors in the discovery document 156 a . stage 606 involves generating resources that are formatted in the second machine - readable language . this is done based on the resource descriptors . for example , the library building unit 114 can generated resources based on resource descriptors in the discovery document 156 a . stage 608 involves attaching the resources to the empty client library to generate the client library . for example , the library building unit 114 can attach resources formatted in the second machine - readable language to the empty client library to generate a client library that enables the client device 110 to interface with the url shortener api 152 a of the server device 150 . the method of fig6 ends at stage 610 . in carrying out the method of fig6 , there are some considerations that should be taken into account . one consideration is the time when the stages 602 , 604 , 606 , and 608 are to be carried out . in one embodiment , the second machine - readable language is a dynamically typed language such as python . this means that creation of the programming structures to interface with apis on the server device 150 can be lazily constructed during the runtime execution phase . fig7 illustrates exemplary instructions 700 that can be used to build a library according to the methods illustrated and described in connection with fig5 and 6 . the instructions 700 are formatted in python . the python instructions 700 enable the client device 110 to receive the discovery document 156 a and , based on the discovery document 156 a , to interface with the url shortener api 152 a of the server device 150 . because python is a dynamically typed language , the python instructions 700 enable the library building unit 114 of the client device 100 to fetch the discovery document 156 a and to generate the library during a runtime phase of execution of the python instructions 700 . line numbers are provided to aid in explaining the features of the python instructions 800 . lines 1 - 5 of the instructions 700 import several libraries that carry resources to be used by the python code 700 . line 6 retrieves the discovery document 156 a that corresponds to the url shortener api 152 a . notably , the instructions 700 directly retrieve the discovery document 156 a without retrieving a directory entry . as illustrated , the discovery document 156 a is received from the url “ https :// www . googleapis . com / discovery / v1 / apis / urlshortener / v1 / rest ”. in lines 7 - 9 , the request body of the discovery document is converted to python format . line 10 defines a base uri for the url shortener api 152 a . lines 12 - 23 compose a request . when a method is called on a collection , the uri template is expanded with the parameters passed into the method , and parameters with a location of “ query ” are put into the query parameters of the url . finally , a request is sent to the composed url using the http method specified in the discovery document 156 a . lines 24 - 29 build the client library surface by recursively descending over the parsed discovery document 156 a . for each method in the methods section , a new method is attached to the “ collection ” object . because collections can be nested , the instructions look for resources and recursively build the collection object for all of its members if any are found . each nested collection is also attached to the collection object as an attribute . lines 30 - 31 demonstrate how the built api client library surface is used . first , a service object is built from the discovery document 156 a . then , a long url ( www . google . com ) is inserted into the url collection of the url shortener api 152 a . the url shortener api 152 a generates a short url based on the long url . for example , when the python instructions 700 are executed , the following response is returned : in this response , “ kind ” indicates the api service (“ urlshortener ”) and the method resource (“ url ”) in the api service , “ id ” indicates the short url (“ http :// goo . gl / fbss ”) that the url shortener api 152 a outputs , and “ longurl ” indicates the long url (“ http :// www . google . com /”) that was provided by the python instructions 700 as an input to the url shortener api 152 a . in an embodiment , the python instructions 700 can receive the name and version of a second api , along with any parameters that are to be used as inputs to the second api . for example , the python instructions 700 can receive the name and version of the location api 152 b , along with a specified version and any parameters to be inputted to the location api 152 b . in this way , a common set of python instructions 700 can be used to enable the client device 110 to interface with multiple apis of the server device 150 . fig8 is a block diagram illustrating an example computing device 800 that can be used in accordance with one or more embodiments of the present disclosure . for example , the client device 110 , the server device 150 , or both can be implemented by the computing device 800 . in a basic configuration 801 , the computing device 800 includes a processor 810 and system memory 820 . a memory bus 830 can be used for communicating between the processor 810 and the system memory 820 . the processor 810 can be of any type , including but not limited to a microprocessor ( μp ), a microcontroller ( μc ), a digital signal processor ( dsp ), or any combination of these . the processor 810 can include one or more levels of caching , such as a level - one cache 811 and a level - two cache 812 , a processor core 813 , and registers 814 . the processor core 813 can include an arithmetic logic unit ( alu ), a floating point unit ( fpu ), a digital signal processing core ( dsp core ), or any combination of these . a memory controller 815 can also be used with the processor 810 , or the memory controller 815 can be an internal part of the processor 810 . the system memory 820 can be of any type , including but not limited to volatile memory ( for example , ram ), non - volatile memory ( for example , rom or flash memory ) or any combination of these . the system memory 820 can include an operating system 821 , one or more applications 822 , and program data 824 . the computing device 800 can have additional features , functionality , or interfaces to facilitate communications between the basic configuration 801 and any devices . for example , a bus / interface controller 840 can be used to facilitate communications between the basic configuration 801 and one or more data storage devices 850 via a storage interface bus 841 . the data storage devices 850 can be removable storage devices 851 , non - removable storage devices 852 , or any combination of these . examples of removable storage and non - removable storage devices include magnetic disk devices such as flexible disk drives and hard - disk drives ( hdd ), optical disk drives such as compact disk ( cd ) drives or digital versatile disk ( dvd ) drives , solid state drives ( ssd ), tape drives , and the like . example computer storage media can include volatile and nonvolatile , removable and non - removable media implemented in any method or technology for storage of information , such as computer readable instructions , data structures , program modules , or other data . the system memory 820 , removable storage 851 and non - removable storage 852 are all examples of computer storage media . computer storage media includes , but is not limited to , ram , rom , eeprom , flash memory or other memory technology , cd - rom , digital versatile disks ( dvd ) or other optical storage , magnetic cassettes , magnetic tape , magnetic disk storage or other magnetic storage devices , or any other medium that can be used to store the desired information and that can be accessed by the computing device 800 . any suitable computer storage media can be part of the computing device 800 . the computing device 800 can also include an interface bus 842 for facilitating communication from various interface devices ( for example , output interfaces , peripheral interfaces , or communication interfaces ) to the basic configuration 801 via the bus / interface controller 840 . example output devices 860 include a graphics processing unit 861 and an audio processing unit 862 , either or which can be configured to communicate to various external devices such as a display or speakers via one or more a / v ports 863 . example peripheral interfaces 870 include a serial interface controller 871 or a parallel interface controller 872 , which can be configured to communicate with external devices such as input devices ( for example , a keyboard , mouse , pen , voice input device , or touch input device ) or other peripheral devices ( for example , a printer or scanner ) via one or more of the i / o ports 873 . an example communication device 880 includes a network controller 881 , which can be arranged to facilitate communications with one or more other computing devices 890 over a network communication ( not shown ) via one or more of the communication ports 882 . the communication connection is one example of a communication media . communication media may typically be embodied by computer readable instructions , data structures , program modules , or other data in a modulated data signal , such as a carrier wave or other transport mechanism , and includes any information delivery media . a modulated data signal can be a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal . communication media includes wired media such as a wired network or direct - wired connection , and wireless media such as acoustic , radio frequency ( rf ), and infrared ( ir ). a computer readable medium includes a storage medium and a communication medium . the computing device 800 can be implemented as a portion of a small - form factor portable electronic device such as a cell phone , a personal data assistant ( pda ), a personal media player device , a wireless web - watch device , a personal headset device , an application specific device , or a hybrid device that include any of these functions . the computing device 800 can also be implemented as a personal computer including both laptop computer and non - laptop computer configurations . the disclosed embodiments can be implemented via application specific integrated circuits ( asics ), field programmable gate arrays ( fpgas ), digital signal processors ( dsps ), or other integrated formats . the disclosed embodiments can be implemented in integrated circuits , as any number of computer programs running on one or more computers , or as firmware . while embodiments have been disclosed , these embodiments are meant to illustrate and are not intended to be limiting , with the true scope and spirit being indicated by the following claims .