Lecture
API (application programming interface) (English: application programming interface, API [ay-pee-eye] ) — a description of the ways (a set of classes, procedures, functions, structures or constants) in which one computer program can interact with another program. It is usually part of the description of an Internet protocol (for example, an RFC ), a software framework, or an operating system function-call standard . It is often implemented as a separate software library or an operating system service. It is used by programmers when writing all kinds of applications.
Application programming interface (API - Application Programming Interface) is an interface that allows different software components to interact with each other.
An API can be applied in several ways:
Application programming interface (API) is a set of ready-made classes, procedures, functions, structures and constants provided by an application (library, service) for use in external software products. It is used by programmers to write various applications.
An API defines the functionality that a program (module, library) provides, while allowing you to abstract away from how that functionality is implemented. If you think of a program (module, library) as a black box, then the API is a set of "knobs" available to the user of that box, which they can turn.
Software components interact with each other through APIs. The components usually form a hierarchy: high-level components use the APIs of low-level components, and those, in turn, use the APIs of even lower-level components.
Put in plainer terms, an API is ready-made code that makes a programmer's life easier. APIs were created so that a programmer could genuinely simplify the task of writing a particular application by using ready-made code (for example, functions). The well-known jQuery, written in JavaScript, is also a kind of API. Taking this example specifically, jQuery makes writing code much easier. What can be done in 30 lines with plain JavaScript takes 5-6 lines with jQuery. Looking at APIs in general, you can find a great many services offering solutions for development. The best known today is code.google.com, which offers about fifty different APIs! These include an interface for building Android applications, various APIs for working with AJAX, and various application APIs that can be easily customized to your own needs.
Application programming interface ( API ) is a connection between computers or between computer programs . It is a type of software interface , offering a service to other pieces of software . A document or standard that describes how to build such a connection or interface is called an API specification . A computer system that meets this standard is said to implement or expose an API. The term API can refer either to the specification or to the implementation.
In contrast to a user interface , which connects a computer to a person, an application programming interface connects computers or pieces of software to each other. It is not intended to be used directly by a human ( the end user ), other than a programmer who incorporates it into software. An API often consists of different parts that act as tools or services available to the programmer. A program or programmer that uses one of these parts is said to call that part of the API. The calls that make up the API are also known as subroutines , methods, requests or endpoints . An API specification defines these calls, that is, it explains how to use or implement them.
One purpose of an API is to hide the internal details of how a system works, exposing only the parts a programmer will find useful and keeping them consistent even if the internal details change later. An API can be designed specifically for a particular pair of systems, or it can be a common standard that enables interoperability among many systems.
The term API is often used to refer to web APIs , which provide communication between computers connected to the Internet . There are also APIs for programming languages , software libraries , computer operating systems and computer hardware . APIs originated in the 1940s, although the term itself only appeared in the 1960s and 1970s.
After all, does it make sense to write code by hand? Why labor over something that has already been created? Does it make sense to turn down free solutions (and in fact free help) in web development? If you answered "NO" to all these questions, then consider that you have grasped the essence of an API.
But I want to add a caveat. Beginner developers should NOT use semi-finished solutions, because in the future they will not be able to cope with a real task. So, if you are a beginner web programmer, do not use ready-made shortcuts! Learn to think for yourself and to build various algorithms in order to grasp the essence of programming. I will also say, now addressing everyone, that an API is not a ready-made solution; it is an environment, an interface for building your own projects. You don't eat frozen cutlets from the store as they are, do you? You fry them first, don't you? This analogy shows the essence of an API very clearly.
An API defines the functionality that a program (module, library) provides, while allowing you to abstract away from exactly how that functionality is implemented.
If you think of a program (module, library) as a black box, then the API is a set of "knobs" available to the user of that box, which they can turn and pull.
Software components interact with each other through APIs. The components usually form a hierarchy: high-level components use the APIs of low-level components, and those, in turn, use the APIs of even lower-level components.
Data transfer protocols on the Internet are built on this principle. The standard protocol stack (the OSI network model) contains 7 layers (from the physical layer of bit transmission to the layer of application protocols such as HTTP and IMAP). Each layer uses the functionality of the previous ("underlying") data transfer layer and, in turn, provides the required functionality to the next ("overlying") layer.
The concept of a protocol is close in meaning to the concept of an API. Both are abstractions of functionality, except that in the first case it concerns data transfer, and in the second, interaction between applications.
The API of a library of functions and classes includes a description of the signatures and semantics of the functions.
A function signature is the part of a function's overall declaration that allows translation tools to identify the function among others. Different programming languages have different notions of a function signature, which is also closely tied to the function overloading capabilities in those languages.
A distinction is sometimes made between a function's call signature and its implementation signature. The call signature is usually derived from the syntactic construct of the function call, taking into account the scope signature of the function, the function name, the sequence of actual argument types in the call, and the result type. The implementation signature usually involves certain elements of the syntactic construct of the function declaration: the function's scope specifier, its name, and the sequence of formal argument types.
For example, in the C++ programming language, a simple function is uniquely identified by the compiler by its name and the sequence of its argument types, which together make up the function's signature in that language. If the function is a method of some class, the class name also becomes part of the signature.
In the Java programming language, a method's signature consists of its name and the sequence of its parameter types; the return type is not part of the signature.
The semantics of a function is a description of what that function does. It includes a description of what the result of evaluating the function is, and how and on what that result depends. Usually the result depends only on the values of the function's arguments, but some modules have the notion of state. In that case the function's result may depend on that state, and, in addition, the result may be a change of state. The logic of these dependencies and changes belongs to the semantics of the function. A complete description of a function's semantics is its executable code or the mathematical definition of the function.
An API opens up a software system for interaction from the outside. It allows two software systems to communicate across a boundary (an interface) using mutually agreed-upon signals. In other words, an API connects software entities together. Unlike a user interface, an API is usually not visible to users. It is part of the software system "under the hood", used for machine-to-machine communication.
A well-designed API exposes only the objects or actions needed by the software or by software developers. It hides details that have no meaning to them. This abstraction simplifies programming.
Figuratively speaking, APIs link software together like interlocking blocks.
Building software using APIs can be compared to using construction sets such as Lego bricks. Software services or software libraries are analogous to the bricks; they can be combined using their APIs to make up a new software product. The process of combining them is called integration .
As an example, consider a weather sensor that offers an API. When a certain message is sent to the sensor, it determines the current weather conditions and responds with a weather forecast. The message that activates the sensor is an API call, and the weather forecast is the API response . A weather forecasting application can integrate with several weather sensor APIs, collecting weather data from across a geographic area.
An API is often compared to a contract . It represents an agreement between parties: the service provider that offers the API, and the software developers who rely on it. If the API remains stable, or if it changes only in predictable ways, developers' trust in the API will grow. This may increase their use of the API.
A 1978 diagram proposing to extend the idea of an API into a general programming interface that goes beyond application programs alone [ 9 ]
The term API initially described an interface only for programs aimed at the end user, known as application programs . This origin is still reflected in the name "application programming interface". Today the term is broader, also including utility software and even hardware interfaces . [ 10 ]
The idea of an API is much older than the term itself. British computer scientists Maurice Wilkes and David Wheeler worked on a modular software library in the 1940s for EDSAC , one of the first computers. The subroutines in this library were stored on punched tape organized in a filing cabinet . This library also contained what Wilkes and Wheeler called a "library catalog" of notes about each subroutine and how to incorporate it into a program. Today such a catalog would be called an API (or an API specification or API documentation), because it instructs the programmer on how to use (or "call") each subroutine the programmer needs.
Wilkes and Wheeler's book "The Preparation of Programs for an Electronic Digital Computer " contains the first published API specification. Joshua Bloch considers that Wilkes and Wheeler "invented" the API without realizing it, since it is more of a concept that was discovered than invented.
Although the people who coined the term API were implementing software on the Univac 1108 , the goal of their API was to make it possible to build programs that are hardware-independent .
The term "application program interface" (without the -ing suffix) is first mentioned in a paper titled " Data structures and techniques for remote computer graphics" , presented at the AFIPS conference in 1968. The authors of that paper use the term to describe the interaction of an application (in this case, a graphics program) with the rest of the computer system. A consistent application interface (consisting of Fortran subroutine calls ) was intended to free the programmer from having to deal with the peculiarities of the graphical display device and to provide hardware independence if the computer or display were replaced. [
The term was introduced into the field of databases by CJ Date in a 1974 paper titled "The Relational and Network Approaches: Comparison of the Application Programming Interface" . The API became part of the ANSI/SPARC framework for database management systems . This framework treated the application programming interface separately from other interfaces, such as the query interface. Database professionals in the 1970s noticed that these various interfaces could be combined; a sufficiently rich application interface could support the other interfaces as well.
This observation led to APIs that supported all types of programming, not just application programming. By 1990, the API was defined simply as "a set of services available to a programmer for performing certain tasks" by technologist Carl Malamud .
A screenshot of Web API documentation written by NASA
The idea of an API was extended again with the dawn of remote procedure calls and web APIs . As computer networks became commonplace in the 1970s and 80s, programmers wanted to call libraries located not only on their local computers but also on computers located elsewhere. These remote procedure calls were well supported by the Java language , in particular. In the 1990s, with the spread of the Internet , standards such as CORBA , COM and DCOM competed to become the most common way of providing API services. [
Roy Fielding's dissertation " Architectural Styles and the Design of Network-based Software Architectures" at the University of California, Irvine in 2000 described Representational State Transfer (REST) and outlined the idea of a "network-based application programming interface", which Fielding contrasted with traditional "library-based" APIs. [ 17 ] XML and JSON web APIs saw widespread commercial adoption starting in 2000 and continuing as of 2021. The web API is now the most common meaning of the term API.
The Semantic Web, proposed by Tim Berners-Lee in 2001, included "semantic APIs" that recast the API as an open , distributed data interface rather than a software behavior interface. Proprietary interfaces and agents became more common than open ones, but the idea of the API as a data interface took hold. Since web APIs are widely used to exchange all kinds of data over the network, API has become a broad term describing much of the communication on the Internet. In this usage, the term API overlaps in meaning with the term communication protocol .
The interface to a software library is one type of API. The API describes and prescribes the "expected behavior" (the specification), whereas the library is the "actual implementation" of this set of rules.
A single API can have multiple implementations (or none, since it is abstract) in the form of different libraries that share the same programming interface.
Separating an API from its implementation can allow programs written in one language to use a library written in another. For example, because Scala and Java compile to compatible bytecode , Scala developers can take advantage of any Java API. [ 19 ]
API usage can vary depending on the type of programming language used. An API for a procedural language such as Lua may consist mainly of basic routines for executing code, manipulating data, or handling errors, while an API for an object-oriented language such as Java will provide a specification of classes and their class methods . [ 20 ] [ 21 ] Hyrum's law states: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." [ 22 ] Meanwhile, several studies show that most applications that use an API tend to use only a small part of the API. [ 23 ]
Language bindings are also APIs. By mapping the functions and capabilities of one language to an interface implemented in another language, a language binding makes it possible to use a library or service written in one language when developing in another language. [ 24 ] Tools such as SWIG and F2PY, a Fortran -to -Python interface generator, make it easier to create such interfaces. [ 25 ]
An API can also be related to a software framework : a framework can be based on several libraries implementing several APIs, but unlike the usual use of an API, access to the behavior built into the framework is achieved by extending its contents with new classes plugged into the framework itself.
Moreover, the overall flow of control of the program can slip out of the caller's control and into the hands of the framework through inversion of control or a similar mechanism. [ 26 ] [ 27 ]
An API can define the interface between an application and an operating system . [ 28 ] For example, POSIX defines a set of common APIs that allow an application written for a POSIX-compliant operating system to be compiled for another POSIX-compliant operating system.
Linux and Berkeley Software Distribution are examples of operating systems that implement the POSIX API
Microsoft has demonstrated a firm commitment to a backward-compatible API, especially in its Windows API (Win32) library, so older applications can run on newer versions of Windows using an executable-specific setting called "Compatibility Mode".
An API differs from an application binary interface (ABI) in that an API is source code-based, while an ABI is binary-based. For example, POSIX provides an API, while the Linux Standard Base provides an ABI.
Remote APIs allow developers to manipulate remote resources through protocols , specific standards for communication that allow different technologies to work together, regardless of language or platform. For example, the Java Database Connectivity API allows developers to query many different types of databases with the same set of functions, while the Java remote method invocation API uses the Java Remote Method Protocol to allow the invocation of functions that operate remotely but appear local to the developer.
Remote APIs are thus useful for maintaining the abstraction of objects in object-oriented programming ; a method call made locally on a proxy object invokes the corresponding method on the remote object, using the remoting protocol, and receives the result for local use as a return value.
Modifying the proxy object will also result in a corresponding modification of the remote object.
Web APIs are defined interfaces through which interaction takes place between an enterprise and the applications that use its assets, which is also a service level agreement (SLA) that specifies the functional provider and provides a service path or URL for API users. The API approach is an architectural approach that revolves around providing a programming interface for a set of services to different applications serving different types of consumers
When used in the context of web development, an API is typically defined as a set of specifications, such as Hypertext Transfer Protocol (HTTP) request messages, along with a definition of the structure of response messages, usually in Extensible Markup Language ( XML ) or JavaScript Object Notation ( JSON ) format. An example is a shipping company's API that can be added to an e-commerce-focused website to make it easier to order shipping services and to automatically include current shipping rates, without the site developer having to enter the shipper's rate table into a web database. Although "web API" has historically been virtually synonymous with web service , the recent trend (the so-called Web 2.0 ) is moving away from Simple Object Access Protocol ( SOAP ) based web services and service-oriented architecture (SOA) toward more direct Representational State Transfer (REST) style web resources and resource-oriented architecture (ROA). Part of this trend is related to the Semantic Web movement toward the Resource Description Framework (RDF), a concept promoting web ontology engineering technologies . Web APIs allow the combination of multiple APIs into new applications known as mashups . In the realm of social media, web APIs have allowed web communities to facilitate the exchange of content and data between communities and applications. In this way, content that is created dynamically in one place can be published and updated in multiple places on the web. For example, Twitter's REST API allows developers to access core Twitter data, and the Search API provides developers with methods to interact with Twitter search and trends data.
Almost all operating systems (UNIX, Windows, OS X, etc.) have an API with which programmers can create applications for that operating system. The main API of operating systems is the set of system calls.
In the software industry, common standard APIs for standard functionality play an important role, since they ensure that all programs using a common API will work equally well, or at least in a typical, familiar way. In the case of graphical interface APIs, this means that programs will have a similar user interface, which makes it easier to learn new software products.
On the other hand, differences in the APIs of different operating systems make it significantly harder to port applications between platforms. There are various ways around this difficulty: writing "intermediate" APIs (GUI APIs such as wxWidgets, GTK, and so on), writing libraries that map the system calls of one OS to the system calls of another OS (runtime environments such as Wine, Cygwin, and so on), introducing coding standards in programming languages (for example, the C standard library), and writing interpreted languages implemented on different platforms (sh, Python, Perl, PHP, Tcl, Java, etc.).
A programmer also often has several different APIs at their disposal that can achieve the same result. In this case, each API is usually implemented using the APIs of software components at a lower level of abstraction.
For example, to see the line "Hello, world!" in a browser, it is enough to create an HTML document with a minimal header and the simplest body containing that line. When the browser opens this document, the browser program passes the file name (or an already open file descriptor) to the library that processes HTML documents; that library, in turn, uses the operating system's API to read the file and work out its structure, then sequentially calls, through the API of the standard graphics primitives library, operations such as "clear the window" and "write "Hello, world!" in the selected font". While these operations run, the graphics primitives library makes the corresponding requests to the window interface library, and that library in turn calls the operating system's API to write data to the video card's buffer.
At almost every one of these levels there are actually several possible alternative APIs. For example, we could write the source document not in HTML but in LaTeX, and we could use any browser for display. Moreover, different browsers use different HTML libraries, and all of this can be built using different primitives libraries and on different operating systems.
The main difficulties of existing multi-level API systems are therefore:
In web development, this is typically a defined set of HTTP requests, along with a definition of the structure of HTTP responses, which are expressed using the XML or JSON formats.
A Web API is practically synonymous with a web service, although recently, due to the Web 2.0 trend, there has been a shift from SOAP to REST as the communication style. Web interfaces that combine several services in new applications are known as hybrids (mashups).
Examples: MediaWiki API
An API for a website - is a script that accepts requests (via GET (site.ru / api.php: A = b) and POST methods) and returns not ordinary HTML for browsers, but the result of the request in a certain format (XML, JSON, php serialize () -ed).
An API is intended not for users but for a script on a third-party site / service / program, which sends these GET / POST requests, receives the result, and uses the data. The script sends requests to perform a certain action (for example, an action that site users perform through a browser).
Programmer-developers need an API for integration with other sites / services / programs, or for automating certain actions. Usually, APIs are created for very popular sites or services.
API design has a significant impact on its use. The principle of information hiding describes the role of programming interfaces as enabling modular programming by hiding the implementation details of modules, so that users of the modules do not need to understand the complexity inside them. Thus, API design tries to provide only the tools the user expects. The design of programming interfaces is an important part of software architecture , the organization of a complex piece of software.
JSON, convenient and human-readable,
Binary and more modern technologies: BSON, CBOR, MessagePack.
Requirements for the data representation format used in REST APIs:
binary;
fast (with Zero-copy support);
schemaless;
supports the existing JSON types for conversion.
For example, MessagePack can speed things up by almost half compared to JSON, which can increase engagement or conversion.
When developing an API, different data formats are used to transfer information between the client and the server. The main ones are JSON, XML, YAML, Protobuf, MessagePack, and Avro. Let us examine their features, advantages, and disadvantages.
| Format | Description | Advantages | Disadvantages | Use cases |
|---|---|---|---|---|
| JSON (JavaScript Object Notation) | A readable text format based on JavaScript objects. | Easily read by humans and machines. Wide support in programming languages. Compresses well. | Inefficient in size (due to duplicated keys). Slower than binary formats. | REST APIs, web services, microservices. |
| XML (Extensible Markup Language) | A tagged text format with a nested structure. | Flexibility and extensibility. Supports validation (XSD, DTD). Human-readable. | Redundancy, large size. Slower than JSON. Complex parsing. | SOAP APIs, configuration files, financial systems. |
| YAML (Yet Another Markup Language) | A simplified markup format, convenient for configuration. | Human-readable. Minimal characters, lighter than JSON and XML. Supports nesting. | Slower than JSON and binary formats. Sensitive to indentation. | Configuration (Kubernetes, Docker, Ansible), OpenAPI. |
| Protobuf (Protocol Buffers) | A binary format from Google for high-performance data transfer. | Compactness and high speed. Good for mobile and IoT applications. Schema support. | Not human-readable. Requires schema compilation (protobuf definition). | gRPC, internal APIs, high-load systems. |
| MessagePack | A binary format optimized for JSON objects. | More compact than JSON. Supports complex data structures. High serialization speed. | Requires a parsing library. Not as widespread as JSON. | IoT, mobile applications, fast APIs. |
| Avro | A binary format with dynamic schemas from Apache. | High performance. Compresses well. Support for schema evolution (without the need for recompilation). | Requires the use of a schema. Less widespread. | Big Data, Apache Kafka, distributed systems. |
If readability and simplicity matter, choose JSON or YAML.
If performance is the priority, use Protobuf or MessagePack.
For Big Data and complex structures, Avro is a better fit.
A widget is a small, self-contained software module built using API technology that runs in some environment (for example, a website, a browser, a mobile phone) and typically performs a single specific function.
Widgets are also called gadgets, informers, and in English gadget, badge, module, webjit, capsule, snippet, mini, or even flake.
Widgets can be divided into groups by the environment in which they run:
This is a code fragment that a user can embed into an HTML page and use without significant modification. Typically, web widgets are created using DHTML, JavaScript, and Adobe Flash technologies.
Web widgets can broadly be divided into:
Interactive widgets, which the user can interact with, for example, to send SMS messages or to look up a route on a map.
Non-interactive widgets, whose content and behavior do not depend on the actions of the user viewing the page. Non-interactive widgets are also often called informers. A classic example of an informer is a weather informer.
These are small tools (programs) that perform a single function and require a special environment to run - a widget engine.
Desktop widgets can show the latest news or a photo slideshow right on the computer desktop, let you take notes on virtual sticky notes, track working hours, and much more.
A wide variety of technologies are used to create desktop widgets: from HTML and JavaScript to C++. Very often, desktop widgets are used to display information from a particular website (for example, a weather forecast) on the desktop without the help of a browser.
Web widgets and phone widgets work on the same principle. A phone widget is a graphical add-on installed on a phone. It usually serves to decorate, entertain, or deliver specific information. To install a widget on a phone, you need a modern phone model (Samsung, WiTu, Nokia, LG, Apple iPhone). The iPhone works almost on the principle of widgets, except that these widgets are entire powerful programs. To fill an iPhone with content, you need to download phone apps from the developer's website.
Operating systems
|
|
|
Graphical interfaces
|
|
|
Audio interfaces
|
|
Authentication systems
|
|
APIs are one of the most common ways for technology companies to integrate. Those who provide and consume APIs are considered members of a business ecosystem.
The main API release policies are:
Private : The API is intended for a company's internal use only.
Partner : The API can be used only by specific business partners. For example, ride-hailing companies such as Uber and Lyft allow approved third-party developers to order rides directly from their apps. This lets the companies exercise quality control by determining which apps have access to the API, and provides them with an additional source of revenue.
An important consideration when an API becomes public is its "interface stability". Changes to an API - for example, adding new parameters to a function call - can break compatibility with clients that depend on that API.
When parts of a publicly exposed API are subject to change and are therefore unstable, those parts of the API should be explicitly documented as "unstable". For example, in the Google Guava library, the parts that are considered unstable and that may change soon are marked with the Java annotation @Beta .
A public API can sometimes declare parts of itself deprecated or retired. This usually means that the part of the API should be considered a candidate for removal or for a backward-incompatible change. Such changes thus allow developers to move away from the parts of the API that will be removed or will not be supported in the future.
Client code may contain innovative or opportunistic uses that the API's developers did not anticipate. In other words, for a library with a significant user base, once an element becomes part of the public API, it can be used in a variety of ways. On February 19, 2020, Akamai published its annual "State of the Internet" report, showing a growing trend of cybercriminals targeting public API platforms in financial services around the world. From December 2017 to November 2019, Akamai witnessed 85.42 billion credential abuse attacks. About 20%, or 16.55 billion, were aimed at hostnames identified as API endpoints. Of these, 473.5 million targeted organizations in the financial services sector.
API documentation describes what services an API offers and how to use them, aiming to cover everything a client needs to know for practical purposes.
Documentation is crucial for developing and maintaining applications that use the API. API documentation is traditionally found in documentation files, but it can also be found on social media such as blogs, forums, and Q&A websites.
Traditional documentation files are often presented through a documentation system such as Javadoc or Pydoc, which has a consistent look and structure. However, the types of content included in the documentation vary from API to API.
For the sake of clarity, API documentation may include a description of the classes and methods in the API, as well as "typical usage scenarios, code snippets, design rationales, performance discussions, and contracts", but the implementation details of the API services themselves are usually omitted. It can take various forms, including tutorials, guides, and reference works. It will also include various types of information, including guides and functionality descriptions.
API usage restrictions and prohibitions are also covered by the documentation. For example, the documentation for an API function may note that its parameters cannot be null, or that the function itself is not thread-safe . Because API documentation is, as a rule, all-encompassing, it becomes difficult for writers to keep the documentation up to date and for users to read it carefully, which can lead to errors.
API documentation can be enriched with metadata, such as Java annotations . This metadata can be used by the compiler, by tools, and by the runtime environment to implement custom behaviors or custom processing.
It is possible to generate API documentation from data. By observing many programs that use a given API, one can infer typical usage patterns as well as required contracts and directives. Templates can then be used to generate natural language from the mined data.
API documentation tools make it easier to create detailed reference documents, guides, and API documentation. These tools help document REST, SOAP, or GraphQL APIs efficiently. They produce comprehensive API documentation that helps developers.
API documentation tools help produce detailed reference materials, simplifying the process of maintaining and updating them. They automatically generate documentation from API specifications and keep it in sync with changes in the code.
The main features of these tools include:
As a result, API documentation becomes clear, interactive, and consistent.
Here is a list of popular tools that help create, manage, and update API documentation:
Automatically generates documentation based on the OpenAPI specification.
Lets you test the API right in the browser.
Includes Swagger UI, Swagger Editor, and Swagger Codegen.
Lets you document APIs in a convenient interface.
Generates interactive documentation with testing capabilities.
Supports automatic documentation updates.
Uses OpenAPI to generate attractive, well-structured documentation.
Supports customization and embedding in web applications.
Lets you create multi-level documentation.
Uses a Markdown-like syntax to describe APIs.
Generates documentation compatible with Apiary.
Lets you write API specifications in a convenient format.
Built on React and designed for convenient documentation maintenance.
Suitable for API documentation, with customization options.
Supports versioning.
Provides interactive and dynamic documentation.
Includes API usage analytics.
Supports versioning and authorization.
Lets you manage API documentation based on OpenAPI and JSON Schema.
Includes a visual API editor.
Integrates with CI/CD.
Generates static, beautifully designed documentation.
Based on Markdown and supports customization.
Suitable for RESTful APIs.
A lightweight and convenient tool for API documentation.
Uses Markdown and supports various themes.
Easy to configure and deploy.
A Microsoft tool for creating API documentation.
Supports C#, .NET, and other technologies.
Generates static documentation.
The choice of tool depends on your needs: Swagger and Redoc are well suited to OpenAPI, Postman is convenient for testing, and Docusaurus and MkDocs are good for text-based documentation.
In 2010, Oracle Corporation sued Google for distributing a new implementation of Java built into the Android operating system. Google had not obtained any permission to reproduce the Java API, although permission had been given to a similar project, OpenJDK. Judge William Alsup ruled in Oracle v. Google that APIs cannot be copyrighted in the United States, and that an Oracle victory would have broadly extended copyright protection to a "functional set of symbols" and allowed copyright on simple program commands:
To accept Oracle's claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own versions of that code to carry out all or part of the same commands.
Alsup's decision was reversed in 2014 on appeal to the Court of Appeals for the Federal Circuit, although the question of whether such use of the API constitutes fair use remained unresolved.
In 2016, after a two-week trial, a jury ruled that Google's reimplementation of the Java API constituted fair use, but Oracle promised to appeal the decision. Oracle won the appeal, and the Federal Circuit ruled that Google's use of the API did not meet the criteria for fair use. In 2019, Google appealed to the U.S. Supreme Court over the copyright infringement and fair use rulings, and the Supreme Court granted the petition for review. Because of the COVID-19 pandemic, oral arguments in the case were postponed until October 2020.
The case was decided by the Supreme Court in favor of Google.
продолжение следует...
Часть 1 API: Application Programming Interface
Comments