Api как пишется

“Api.php” redirects here. For the Wikipedia API, see Special:ApiHelp.

An application programming interface (API) is a way for two or more computer programs to communicate with each other. It is a type of software interface, offering a service to other pieces of software.^[1] A document or standard that describes how to build or use 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 may refer either to the specification or to the implementation.

In contrast to a user interface, which connects a computer to a pen, an application programming interface connects computers or pieces of software to each other. It is not intended to be used directly by a person (the end user) other than a computer programmer who is incorporating it into the software. An API is often made up of different parts which act as tools or services that are available to the programmer. A program or a programmer that uses one of these parts is said to call that portion 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, meaning that it explains how to use or implement them.

One purpose of APIs is to hide the internal details of how a system works, exposing only those parts a programmer will find useful and keeping them consistent even if the internal details later change. An API may be custom-built for a particular pair of systems, or it may be a shared standard allowing interoperability among many systems.

There are APIs for programming languages, software libraries, computer operating systems, and computer hardware. APIs originated in the 1940s, though the term did not emerge until the 1960s and 1970s.
Contemporary usage of the term API often refers to web APIs,^[2] which allow communication between computers that are joined by the internet.
Recent developments in APIs have led to the rise in popularity of microservices, which are loosely coupled services accessed through public APIs.^[3]

Purpose[edit]

In building applications, an API simplifies programming by abstracting the underlying implementation and only exposing objects or actions the developer needs. While a graphical interface for an email client might provide a user with a button that performs all the steps for fetching and highlighting new emails, an API for file input/output might give the developer a function that copies a file from one location to another without requiring that the developer understand the file system operations occurring behind the scenes.^[4]

History of the term[edit]

The term API initially described an interface only for end-user-facing programs, known as application programs. This origin is still reflected in the name “application programming interface.” Today, the term is broader, including also utility software and even hardware interfaces.^[6]

1940s and 1950s[edit]

The idea of the 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, an early computer. The subroutines in this library were stored on punched paper tape organized in a filing cabinet. This cabinet 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 a programmer on how to use (or “call”) each subroutine that the programmer needs.^[6]

Wilkes and Wheeler’s 1951 book The Preparation of Programs for an Electronic Digital Computer contains the first published API specification. Joshua Bloch considers that Wilkes and Wheeler “latently invented” the API because it is more of a concept that is discovered than invented.^[6]

1960s and 1970s[edit]

The term “application program interface” (without an -ing suffix) is first recorded in a paper called Data structures and techniques for remote computer graphics presented at an AFIPS conference in 1968.^[8][6] The authors of this paper use the term to describe the interaction of an application—a graphics program in this case—with the rest of the computer system. A consistent application interface (consisting of Fortran subroutine calls) was intended to free the programmer from dealing with idiosyncrasies of the graphics display device, and to provide hardware independence if the computer or the display were replaced.^[7]

The term was introduced to the field of databases by C. J. Date^[9] in a 1974 paper called The Relational and Network Approaches: Comparison of the Application Programming Interface.^[10] An API became a 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 observed these different interfaces could be combined; a sufficiently rich application interface could support the other interfaces as well.^[5]

This observation led to APIs that supported all types of programming, not just application programming.

1990s[edit]

By 1990, the API was defined simply as “a set of services available to a programmer for performing certain tasks” by technologist Carl Malamud.^[11]

The idea of the API was expanded again with the dawn of remote procedure calls and web APIs. As computer networks became common in the 1970s and 1980s, programmers wanted to call libraries located not only on their local computers but 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 like CORBA, COM, and DCOM competed to become the most common way to expose API services.^[12]

2000s[edit]

Roy Fielding’s dissertation Architectural Styles and the Design of Network-based Software Architectures at UC Irvine in 2000 outlined Representational state transfer (REST) and described the idea of a “network-based Application Programming Interface” that Fielding contrasted with traditional “library-based” APIs.^[13] XML and JSON web APIs saw widespread commercial adoption beginning in 2000 and continuing as of 2022. The web API is now the most common meaning of the term API.^[2]

The Semantic Web proposed by Tim Berners-Lee in 2001 included “semantic APIs” that recasts the API as an open, distributed data interface rather than a software behavior interface.^[14] Proprietary interfaces and agents became more widespread than open ones, but the idea of the API as a data interface took hold. Because web APIs are widely used to exchange data of all kinds online, API has become a broad term describing much of the communication on the internet.^[12] When used in this way, the term API has overlap in meaning with the term communication protocol.

Usage[edit]

Libraries and frameworks[edit]

The interface to a software library is one type of API. The API describes and prescribes the “expected behavior” (a specification) while the library is an “actual implementation” of this set of rules.

A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface.

The separation of the 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.^[15]

API use can vary depending on the type of programming language involved.
An API for a procedural language such as Lua could consist primarily of basic routines to execute code, manipulate data or handle errors while an API for an object-oriented language, such as Java, would provide a specification of classes and its class methods.^[16][17] Hyrum’s law ^[18] states that “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.” Meanwhile, several studies show that most applications that use an API tend to use a small part of the API.^[19]

Language bindings are also APIs. By mapping the features and capabilities of one language to an interface implemented in another language, a language binding allows a library or service written in one language to be used when developing in another language.^[20]

Tools such as SWIG and F2PY, a Fortran-to-Python interface generator, facilitate the creation of such interfaces.^[21]

An API can also be related to a software framework: a framework can be based on several libraries implementing several APIs, but unlike the normal use of an API, the access to the behavior built into the framework is mediated by extending its content with new classes plugged into the framework itself.

Moreover, the overall program flow of control can be out of the control of the caller and in the framework’s hands by inversion of control or a similar mechanism.^[22][23]

Operating systems[edit]

An API can specify the interface between an application and the operating system.^[24] POSIX, for example, provides a set of common API specifications that aim to enable an application written for a POSIX conformant operating system to be compiled for another POSIX conformant operating system.

Linux and Berkeley Software Distribution are examples of operating systems that implement the POSIX APIs.^[25]

Microsoft has shown a strong commitment to a backward-compatible API, particularly within its Windows API (Win32) library, so older applications may run on newer versions of Windows using an executable-specific setting called “Compatibility Mode”.^[26]

An API differs from an application binary interface (ABI) in that an API is source code based while an ABI is binary based. For instance, POSIX provides APIs while the Linux Standard Base provides an ABI.^[27][28]

Remote APIs[edit]

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 invocation of functions that operate remotely but appear local to the developer.^[29][30]

Therefore, remote APIs are useful in maintaining the object abstraction in object-oriented programming; a method call, executed locally on a proxy object, invokes the corresponding method on the remote object, using the remoting protocol, and acquires the result to be used locally as a return value.

A modification of the proxy object will also result in a corresponding modification of the remote object.^[31]

Web APIs[edit]

Web APIs are a service accessed from client devices (Mobile Phones, Laptop, etc.) to a web server using the Hypertext Transfer Protocol (HTTP). Client devices send a request in the form of an HTTP request, and are met with a response message usually in JavaScript Object Notation (JSON) or Extensible Markup Language (XML) format. Developers typically use Web APIs to query a server for a specific set of data from that server.

An example might be a shipping company API that can be added to an eCommerce-focused website to facilitate ordering shipping services and automatically include current shipping rates, without the site developer having to enter the shipper’s rate table into a web database. While “web API” historically has been virtually synonymous with web service, the recent trend (so-called Web 2.0) has been moving away from Simple Object Access Protocol (SOAP) based web services and service-oriented architecture (SOA) towards more direct representational state transfer (REST) style web resources and resource-oriented architecture (ROA).^[32] Part of this trend is related to the Semantic Web movement toward Resource Description Framework (RDF), a concept to promote web-based ontology engineering technologies. Web APIs allow the combination of multiple APIs into new applications known as mashups.^[33]

In the social media space, web APIs have allowed web communities to facilitate sharing content and data between communities and applications. In this way, content that is created in one place dynamically can be posted and updated to multiple locations on the web.^[34] For example, Twitter’s REST API allows developers to access core Twitter data and the Search API provides methods for developers to interact with Twitter Search and trends data.^[35]

Design[edit]

The design of an API has a significant impact on its usage.^[4] First of all, the design of programming interfaces represents an important part of software architecture, the organization of a complex piece of software.^[36] The principle of information hiding describes the role of programming interfaces as enabling modular programming by hiding the implementation details of the modules so that users of modules need not understand the complexities inside the modules.^[37]
Aside from the previous underlying principle, other metrics for measuring the usability of an API may include properties such as functional efficiency, overall correctness, and learnability for novices.^[38] One straightforward and commonly adopted way of designing APIs is to follow Nielsen’s heuristic evaluation guidelines. The Factory method pattern is also typical in designing APIs due to their reusable nature.^[39] Thus, the design of an API attempts to provide only the tools a user would expect.^[4]

Synchronous versus asynchronous[edit]

An application programming interface can be synchronous or asynchronous. A synchronous API call is a design pattern where the call site is blocked while waiting for the called code to finish.^[40] With a asynchronous API call, however, the call site is not blocked while waiting for the called code to finish, and instead the calling thread is notified when the reply arrives.

Security[edit]

API security is very critical when developing a public facing API. Common threats include SQL injection, Denial-of-service attack (DoS), broken authentication, and exposing sensitive data.^[41] Without ensuring proper security practices bad actors can get access to information they should not have or even gain privileges to make changes to your server. Some common security practices include proper connection security using HTTPS, content security to mitigate data injection attacks, and requiring an API key to use your service.^[42] Many public facing API services require you to use an assigned API key, and will refuse to serve data without sending the key with your request.^[43]

Release policies[edit]

APIs are one of the more common ways technology companies integrate. Those that provide and use APIs are considered as being members of a business ecosystem.^[44]

The main policies for releasing an API are:^[45]

• Private: The API is for internal company use only.
• Partner: Only specific business partners can use the API. For example, vehicle for hire companies such as Uber and Lyft allow approved third-party developers to directly order rides from within their apps. This allows the companies to exercise quality control by curating which apps have access to the API and provides them with an additional revenue stream.^[46]
• Public: The API is available for use by the public. For example, Microsoft makes the Windows API public, and Apple releases its API Cocoa so that software can be written for their platforms. Not all public APIs are generally accessible by everybody. For example, Internet service providers like Cloudflare or Voxility, use RESTful APIs to allow customers and resellers access to their infrastructure information, DDoS stats, network performance, or dashboard controls.^[47] Access to such APIs is granted either by “API tokens”, or customer status validations.^[48]

Public API implications[edit]

An important factor when an API becomes public is its “interface stability”. Changes to the API—for example adding new parameters to a function call—could break compatibility with the clients that depend on that API.^[49]

When parts of a publicly presented API are subject to change and thus not stable, such parts of a particular API should be documented explicitly as “unstable”. For example, in the Google Guava library, the parts that are considered unstable, and that might change soon, are marked with the Java annotation @Beta.^[50]

A public API can sometimes declare parts of itself as deprecated or rescinded. This usually means that part of the API should be considered a candidate for being removed, or modified in a backward incompatible way. Therefore, these changes allow developers to transition away from parts of the API that will be removed or not supported in the future.^[51]

On February 19, 2020, Akamai published their annual “State of the Internet” report, showcasing the growing trend of cybercriminals targeting public API platforms at financial services worldwide. From December 2017 through November 2019, Akamai witnessed 85.42 billion credential violation attacks. About 20%, or 16.55 billion, were against hostnames defined as API endpoints. Of these, 473.5 million have targeted financial services sector organizations.^[52]

Documentation[edit]

API documentation describes the services an API offers and how to use those services, aiming to cover everything a client would need to know for practical purposes.

Documentation is crucial for the development and maintenance of applications using the API.^[53]
API documentation is traditionally found in documentation files but can also be found in social media such as blogs, forums, and Q&A websites.^[54]

Traditional documentation files are often presented via a documentation system, such as Javadoc or Pydoc, that has a consistent appearance and structure.
However, the types of content included in the documentation differ from API to API.^[55]

In the interest of clarity, API documentation may include a description of classes and methods in the API as well as “typical usage scenarios, code snippets, design rationales, performance discussions, and contracts”, but implementation details of the API services themselves are usually omitted.

Reference documentation for a REST API can be generated automatically from an OpenAPI document, which is a machine-readable text file that uses a prescribed format and syntax defined in the OpenAPI Specification. The OpenAPI document defines basic information such as the API’s name and description, as well as describing operations the API provides access to.^[56]

API documentation can be enriched with metadata information like Java annotations. This metadata can be used by the compiler, tools, and by the run-time environment to implement custom behaviors or custom handling.^[57]

Dispute over copyright protection for APIs[edit]

In 2010, Oracle Corporation sued Google for having distributed a new implementation of Java embedded in the Android operating system.^[58] Google had not acquired any permission to reproduce the Java API, although permission had been given to the similar OpenJDK project. Google had approached Oracle to negotiate a license for their API, but were turned down due to trust issues. Despite the disagreement, Google chose to use Oracle’s code anyway. Judge William Alsup ruled in the Oracle v. Google case that APIs cannot be copyrighted in the U.S and that a victory for Oracle would have widely expanded copyright protection to a “functional set of symbols” and allowed the copyrighting of simple software 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 its different versions to carry out all or part of the same commands.^[59][60]

Alsup’s ruling was overturned in 2014 on appeal to the Court of Appeals for the Federal Circuit, though the question of whether such use of APIs constitutes fair use was left unresolved.^[61][62]

In 2016, following a two-week trial, a jury determined that Google’s reimplementation of the Java API constituted fair use, but Oracle vowed to appeal the decision.^[63] Oracle won on its appeal, with the Court of Appeals for the Federal Circuit ruling that Google’s use of the APIs did not qualify for fair use.^[64] In 2019, Google appealed to the Supreme Court of the United States over both the copyrightability and fair use rulings, and the Supreme Court granted review.^[65] Due to the COVID-19 pandemic, the oral hearings in the case were delayed until October 2020.^[66]

The case was decided by the Supreme Court in Google’s favor with a ruling of 6–2. Justice Stephen Breyer delivered the opinion of the court and at one point mentioned that “The declaring code is, if copyrightable at all, further than are most computer programs from the core of copyright.” This means the code used in APIs are more similar to dictionaries than novels in terms of copyright protection.^[67]

Examples[edit]

See also[edit]

References[edit]

Further reading[edit]

• Taina Bucher (16 November 2013). “Objects of Intense Feeling: The Case of the Twitter API”. Computational Culture (3). ISSN 2047-2390. Argues that “APIs are far from neutral tools” and form a key part of contemporary programming, understood as a fundamental part of culture.
• What is an API? – in the U.S. Supreme Court opinion, Google v. Oracle 2021, pp. 3–7 – “For each task, there is computer code; API (also known as Application Programming Interface) is the method for calling that ‘computer code’ (instruction – like a recipe – rather than cooking instruction, this is machine instruction) to be carry out”
• Maury, Innovation and Change – Cory Ondrejka February 28, 2014 ” …proposed a public API to let computers talk to each other”. (Textise URL)

External links[edit]

• Forrester : IT industry : API Case : Google v. Oracle – May 20, 2021 – content format: Audio with text – length 26:41

Эта статья — об интерфейсах программирования. Об организации, использующей аббревиатуру API, см. Американский институт нефти.

API (МФА: [ˌeɪ.piˈaɪ]; аббр. от англ. Application Programming Interface^[1]) — описание способов взаимодействия одной компьютерной программы с другими. Обычно входит в описание какого-либо интернет-протокола (например, SCIM^[2]), программного каркаса (фреймворка^[3]) или стандарта вызовов функций операционной системы^[4]. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.

Проще говоря, это набор компонентов, с помощью которых компьютерная программа (бот или же сайт) может использовать другую программу.

Назначение[править | править код]

API (интерфейс прикладного программирования) упрощает процесс программирования при создании приложений, абстрагируя базовую реализацию и предоставляя только объекты или действия, необходимые разработчику. Если графический интерфейс для почтового клиента может предоставить пользователю кнопку, которая выполнит все шаги для выборки и выделения новых писем, то API для ввода/вывода файлов может дать разработчику функцию, которая копирует файл из одного места в другое, не требуя от разработчика понимания операций файловой системы, происходящих за кулисами^[5].

API как средство интеграции приложений[править | править код]

Если программу (модуль, библиотеку) рассматривать как чёрный ящик, то API — это набор «ручек», которые доступны пользователю данного ящика и которые он может вертеть и переключать.

Программные компоненты взаимодействуют друг с другом посредством API. При этом обычно компоненты образуют иерархию — высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API ещё более низкоуровневых компонентов.

По такому принципу построены протоколы передачи данных по Интернету. Стандартный стек протоколов (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего («нижележащего») уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему («вышележащему») уровню.

Понятие протокола близко по смыслу к понятию API. И то, и другое является абстракцией функциональности, только в первом случае речь идёт о передаче данных, а во втором — о взаимодействии приложений.

API библиотеки функций и классов включает в себя описание сигнатур и семантики функций.

Сигнатура функции[править | править код]

Сигнатура функции — часть общего объявления функции, позволяющая средствам трансляции идентифицировать функцию среди других. В различных языках программирования существуют разные представления о сигнатуре функции, что также тесно связано с возможностями перегрузки функций в этих языках.

Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учётом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, её имя и последовательность формальных типов аргументов.

Например, в языке программирования C++ простая функция однозначно опознаётся компилятором по своему имени и последовательности типов своих аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет участвовать и имя класса.

В языке программирования Java сигнатуру метода составляют его имя и последовательность типов параметров; тип возвращаемого значения в сигнатуре не участвует^[6].

Семантика функции[править | править код]

Семантика функции — это описание того, что данная функция делает. Семантика функции включает в себя описание того, что является результатом вычисления функции, как и от чего этот результат зависит. Обычно результат выполнения зависит только от значений аргументов функции, но в некоторых модулях есть понятие состояния. Тогда результат функции может зависеть от этого состояния, и, кроме того, результатом может стать изменение состояния. Логика этих зависимостей и изменений относится к семантике функции. Полным описанием семантики функций является исполняемый код функции или математическое определение функции.

API операционных систем. Проблемы, связанные с многообразием API[править | править код]

Практически все операционные системы (UNIX, Windows, OS X, Linux и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем — это множество системных вызовов.

В индустрии программного обеспечения общие стандартные API для стандартной функциональности играют важную роль, так как они гарантируют, что все программы, использующие общий API, будут работать одинаково хорошо или, по крайней мере, типичным привычным образом. В случае API графических интерфейсов это означает, что программы будут иметь похожий пользовательский интерфейс, что облегчает процесс освоения новых программных продуктов.

С другой стороны, различия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности — написание «промежуточных» API (API графических интерфейсов wxWidgets, GTK и т. п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine, cygwin и т. п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека языка C), написание интерпретируемых языков, реализуемых на разных платформах (sh, Python, Perl, PHP, Tcl, Javascript, Ruby и т. д.).

Также в распоряжении программиста часто находится несколько различных API, позволяющих добиться одного и того же результата. При этом каждый API обычно реализован с использованием API программных компонент более низкого уровня абстракции.

Например: для того, чтобы увидеть в браузере строчку «Hello, world!», достаточно лишь создать HTML-документ с минимальным заголовком и простейшим телом, содержащим данную строку. Когда браузер откроет этот документ, программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл и разберётся в его устройстве, затем последовательно вызовет через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать „Hello, world!“ выбранным шрифтом». Во время выполнения этих операций библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы, чтобы записать данные в буфер видеокарты.

При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать любой браузер. К тому же различные браузеры используют различные HTML-библиотеки, и, кроме того, всё это может быть собрано с использованием различных библиотек примитивов и на различных операционных системах.

Основными сложностями существующих многоуровневых систем API, таким образом, являются:

• Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);
• Потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.

Наиболее известные API[править | править код]

Операционных систем

• Cocoa
• Linux Kernel API^[en]
• OS/2 API
• Windows API

Графических интерфейсов

Звуковых интерфейсов

Аутентификационных систем

Web API[править | править код]

Используется в веб-разработке — содержит, как правило, определённый набор HTTP-запросов, а также определение структуры HTTP-ответов, для выражения которых чаще всего используют XML− или JSON−формат, а так же ProtoBuf, XDR и некоторые другие.

Web API является практически синонимом для веб-службы, хотя в последнее время за счёт тенденции Web 2.0 осуществлён переход от SOAP к REST типу коммуникации. Веб-интерфейсы, обеспечивающие сочетание нескольких сервисов в новых приложениях, известны как гибридные.

Пример: MediaWiki API

См. также[править | править код]

• Двоичный интерфейс приложений
• Абстрактный тип данных
• Повторное использование кода

Примечания[править | править код]

Автор: Вячеслав Михайлов, Solutions Architect.

В этой статье я поделюсь опытом проектирования RESTful API — на конкретных примерах покажу, как делать хотя бы простые сервисы красиво. Также мы поговорим, что такое API и зачем он нужен, поговорим об основах REST — обсудим, на чем его можно реализовывать; коснемся основных веб-практик, которые зависят и не зависят от этой технологии. Также узнаем, как составлять хорошую документацию, затрачивая на это минимум усилий, и посмотрим, какие существуют способы нумерации версий для RESTful API.

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  • XML-RPC and JSON-RPC
  • SOAP
  • REST

• WebSockets APIs
• Library-based APIs
  • Java Script

• Class-based APIs
  • C# API
  • Java

Виды API по категориям применения:

• OS function and routines
  • Access to file system
  • Access to user interface

• Object remoting APIs
  • CORBA
  • .Net remoting

• Hardware APIs
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …

Как мы видим, к Web API относятся XML-RPC и JSON-RPC, SOAP и REST.

RPC (remote procedure call — «удаленный вызов процедур») — понятие очень старое, объединяющие древние, средние и современные протоколы, которые позволяют вызвать метод в другом приложении. XML-RPC — протокол, появившийся в 1998 г. вскоре после появления XML. Изначально он поддерживался Microsoft, но вскоре Microsoft полностью переключилась на SOAP, поэтому в .Net Framework мы не найдем классов для поддержки этого протокола. Несмотря на это, XML-RPC продолжает жить до сих пор в различных языках (особенно в PHP) — видимо, заслужил любовь разработчиков простотой.

SOAP также появился в 1998 г. стараниями Microsoft. Он был анонсирован как революция в мире ПО. Нельзя сказать, что все пошло по плану Microsoft: было огромное количество критики из-за сложности и тяжеловесности протокола. В то же время, были и те, кто считал SOAP настоящим прорывом. Протокол продолжал развиваться и плодиться десятками новых и новых спецификаций, пока в 2003 г. W3C не утвердила в качестве рекомендации SOAP 1.2, который и сейчас — последний. Семейство у SOAP получилось внушительное: WS-Addressing, WS-Enumeration, WS-Eventing, WS-Transfer, WS-Trust, WS-Federation, Web Single Sign-On.

Затем, что закономерно, все же появился действительно простой подход — REST. Аббревиатура REST расшифровывается как representational state transfer — «передача состояния представления» или, лучше сказать, представление данных в удобном для клиента формате. Термин “REST” был введен Роем Филдингом в 2000 г. Основная идея REST в том, что каждое обращение к сервису переводит клиентское приложение в новое состояние. По сути, REST — не протокол и не стандарт, а подход, архитектурный стиль проектирования API.

Каковы принципы REST?

• Клиент-серверная архитектура — без этого REST немыслим.
• Любые данные — ресурс.
• Любой ресурс имеет ID, по которому можно получить данные.
• Ресурсы могут быть связаны между собой — для этого в составе ответа передается либо ID, либо, как чаще рекомендуется, ссылка. Но я пока не дошел до того, чтобы все было настолько хорошо, чтобы можно было легко использовать ссылки.
• Используются стандартные методы HTTP (GET, POST, PUT, DELETE) — т. к. они уже заложены в составе протокола, мы их можем использовать для того, чтобы построить каркас взаимодействия с нашим сервером.
• Сервер не хранит состояние — это значит, сервер не отделяет один вызов от другого, не сохраняет все сессии в памяти. Если у вас есть какое-либо масштабируемое облако, какая-то ферма из серверов, которая реализует ваш сервис, нет необходимости обеспечивать согласованность состояния этих сервисов между всеми узлами, которые у вас есть. Это сильно упрощает масштабирование — при добавлении еще одного узла все прекрасно работает.

Чем REST хорош?

• Он очень прост!
• Мы переиспользуем существующие стандарты, которые в ходу уже очень давно и применяются на многих устройствах.
• REST основывается на HTTP => доступны все плюшки:
  • Кэширование.
  • Масштабирование.
  • Минимум накладных расходов.
  • Стандартные коды ошибок.

• Очень хорошая распространенность (даже IoT-устройства уже умеют работать на HTTP).

Лучшие решения (независимые от технологий)

Какие в современном мире есть лучшие решения, не связанные с конкретной реализацией? Эти решения советую использовать обязательно:

• SSL повсюду — самое важное в вашем сервисе, т. к. без SSL авторизация и аутентификация бессмысленны.
• Документация и версионность сервиса — с первого дня работы.
• Методы POST и PUT должны возвращать обратно объект, который они изменили или создали, — это позволит сократить время обращения к сервису вдвое.
• Поддержка фильтрации, сортировки и постраничного вывода — очень желательно, чтобы это было стандартно и работало «из коробки».
• Поддержка MediaType. MediaType — способ сказать серверу, в каком формате вы хотите получить содержимое. Если вы возьмете какую-либо стандартную реализацию web API и зайдете туда из браузера, API отдаст вам XML, а если зайдете через какой-нибудь Postman, он вернет JSON.
• Prettyprint & gzip. Не минимизируйте запросы и не делайте компакт для JSON (того ответа, который придет от сервера). Накладные расходы на prettyprint —единицы процентов, что видно, если посмотреть, сколько занимают табы по отношению к общему размеру сообщения. Если вы уберете табы и будете присылать все в одну строку, запаритесь с отладкой. Что касается gzip, он дает выигрыш в разы. Т. ч. очень советую использовать и prettyprint, и gzip.
• Используйте только стандартный механизм кэширования (ETag) и Last-Modified (дата последнего изменения) — этих двух параметров серверу достаточно, чтобы клиент понял, что содержимое не требует обновления. Придумывать что-то свое тут не имеет смысла.
• Всегда используйте стандартные коды ошибок HTTP. Иначе вам однажды придется кому-нибудь объяснять, почему вы решили, что ошибку 419 в вашем проекте клиенту нужно трактовать именно так, как вы почему-то придумали. Это неудобно и некрасиво — за это клиент вам спасибо не скажет!

Свойства HTTP-методов

Сегодня мы будем говорить только про GET, POST, PUT, DELETE.

Если говорить вкратце об остальных, представленных в таблице, OPTIONS — получение настроек безопасности, HEAD — получение заголовков без тела сообщения, PATCH — частичное изменение содержимого.

Как вы видите, все методы, кроме POST, представленные в таблице, идемпотентны. Идемпотентность — возможность выполнить одно и то же обращение к сервису несколько раз, при этом ответ каждый раз будет одинаковым. Другими словами, не важно, по какой причине и сколько раз вы выполнили это действие. Допустим, вы выполняли действие по изменению объекта (PUT), и вам пришла ошибка. Вы не знаете, что ее вызвало и в какой момент, вы не знаете, изменился объект или нет. Но, благодаря идемпотентности, вы гарантированно можете выполнить этой действие еще раз, т. ч. клиенты могут быть спокойны за целостность своих данных.

“Safe” же значит, что обращение к серверу не изменяет содержимое. Так, GET может быть вызван много раз, но он не изменит никакого содержимого. Если бы он изменял содержимое, в силу того, что GET может быть закэширован, вам пришлось бы бороться с кэшированием, изобретать какие-нибудь хитрые параметры.

Часть 2. Практика

Выбираем технологию

Теперь, когда мы поняли, как работает REST, можем приступить к написанию RESTful API ¬ сервиса, отвечающего принципам REST. Начнем с выбора технологии.

Первый вариант — WCF Services. Все, кто работал с этой технологией, обычно возвращаться к ней больше не хотят — у нее есть серьезные недостатки и мало плюсов:
– webHttpBinding only (а зачем тогда остальные?..).
– Поддерживаются только HTTP Get & POST (и все).
+ Разные форматы XML, JSON, ATOM.

Второй вариант — Web API. В этом случае плюсы очевидны:
+ Очень простой.
+ Открытый исходный код.
+ Все возможности HTTP.
+ Все возможности MVC.
+ Легкий.
+ Тоже поддерживает кучу форматов.

Естественно, мы выбираем Web API. Теперь выберем подходящий хостинг для Web API.

Выбираем хостинг для Web API

Тут есть достаточно вариантов:

• ASP.NET MVC (старый добрый).
• Azure (облачная структура).
• OWIN — Open Web Interface for .NET (свежая разработка от Microsoft).
• IIS
• Self-hosted

OWI
OWIN — не платформа и не библиотека, а спецификация, которая устраняет сильную связанность веб-приложения с реализацией сервера. Она позволяет запускать приложения на любой платформе, поддерживающей OWIN, без изменений. На самом деле, спецификация очень проста — это просто «словарь» из параметров и их значений. Базовые параметры определены в спецификации.

OWIN сводится к очень простой конструкции:

По схеме мы видим, что есть хост, на котором есть сервер, который поддерживает очень простой «словарь», состоящий из перечня «параметр — значение». Все модули, которые подключаются к этому серверу, конфигурируются именно так. Сервер, поддерживающий этот контракт, привязанный к определенной платформе, умеет распознавать все эти параметры и инициализировать инфраструктуру соответствующим образом. Получается, что, если вы пишете сервис, который работает с OWIN, можете свободно, без изменений кода, переносить его между платформами и использовать то же самое на других ОС.

Katana — реализация OWIN от Microsoft. Она позволяет размещать OWIN-сборки в IIS. Вот так она выглядит, очень просто:

[assembly: OwinStartup(typeof (Startup))]
namespace RestApiDemo
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            var config = new HttpConfiguration();
            config.MapHttpAttributeRoutes();            
            app.UseWebApi(config);
        }
    }
}

Вы указываете, какой класс является у вас Startup. Это простой dll, который поднимается IIS. Вызывается конфигуратор. Этого кода достаточно, чтобы все заработало.

Проектируем интерфейс

Теперь спроектируем интерфейс и посмотрим, как все должно выглядеть и каким правилам соответствовать. Все ресурсы в REST — существительные, то, что можно пощупать и потрогать.

Как пример возьмем простую модель с расписанием движения поездов на станциях. Вот примеры простейших запросов REST:

• Корневые (независимые) сущности API:
  • GET /stations — получить все вокзалы.
  • GET /stations/123 — получить информацию по вокзалу с ID = 123.
  • GET /trains — расписание всех поездов.

• Зависимые (от корневой) сущности:
  • GET /stations/555/departures — поезда, уходящие с вокзала 555.

Далее я еще расскажу про DDD, почему мы делаем именно так.

Контроллер

Итак, у нас есть станции, и теперь нам нужно написать простейший контроллер:

[RoutePrefix("stations")]
public class RailwayStationsController : ApiController
{
  [HttpGet]
  [Route]
  public IEnumerable<RailwayStationModel> GetAll()
  {
    return testData;
  }

  RailwayStationModel[] testData = /*initialization here*/
}

Это роутинг, построенный на атрибутах. Здесь мы указываем имя контроллера и просим отдать список (в данном случае — случайные тестовые данные).

OData (www.odata.org)

Теперь представьте, что у вас больше данных, чем нужно на клиенте (больше ста тащить вряд ли имеет смысл). При этом писать самому какое-либо разбиение на страницы, конечно, совсем не хочется. Вместо этого есть простой способ — использовать легкую версию OData, которая поддерживается Web API.

[RoutePrefix("stations")] 
public class RailwayStationsController : ApiController
{
  [HttpGet]
  [Route]
  [EnableQuery]
  public IQueryable<RailwayStationModel> GetAll()
  {
    return testData.AsQueryable();
  }

  RailwayStationModel[] testData = /*initialization here*/
}

IQueryable позволяет вам использовать несколько простых, но эффективных механизмов фильтрации и управления данными на клиентской стороне. Единственное, что нужно сделать, — подключить OData-сборку из NuGet, указать EnableQuery и возвращать интерфейс iQueryable.

Основное отличие такой облегченной верси от полноценной в том, что здесь нет контроллера, который возвращает метаданные. Полноценная OData немного изменяет ответ (заворачивает в спец. Обертку модель, которую вы собираетесь возвращать) и умеет возвращать связанное дерево объектов, которые вы хотите ей отдать. Также облегченная версия OData не умеет делать штуки вроде join, count и т. д.

Параметры запросов

А вот что можно делать:

• $filter — фильтр, по имени, например. Все функции можно посмотреть на сайте OData — они очень помогают и позволяют существенно ограничить выборку.
• $select — очень важная штука. Если у вас большая коллекция и все объекты толстые, но при этом вам нужно сформировать какой-то dropdown, в котором нет ничего, кроме ID и имени, которое вы хотите отобразить, — поможет эта функция, которая упростит и ускорит взаимодействие с сервером.
• $orderby — сортировка.
• $top и $skip — ограничение по выборкам.

Этого достаточно, чтобы самому не изобретать велосипеда. Все это умеет стандартная JS-библиотека вроде Breeze.

EnableQuery Attribute

На самом деле OData — такая штука, которой очень легко можно выстрелить себе в ногу. Если у вас в таблице миллионы записей, и вам нужно тянуть их с сервера на клиент, это будет тяжело, а если таких запросов будет много — совсем смертельно.

Именно для таких случаев у атрибута EnableQuery (см. код выше) есть такой набор параметров, с помощью которых очень многое можно ограничить: не давать больше строк, чем надо, не давать делать join, арифметические операции и т. д. При этом писать самому ничего не надо.

• AllowedArithmeticOperators
• AllowedFunctions
• AllowedLogicalOperators
• AllowedOrderByProperties
• AllowedQueryOptions
• EnableConstantParameterization
• EnsureStableOrdering
• HandleNullPropagation
• MaxAnyAllExpressionDepth
• MaxExpansionDepth
• MaxNodeCount
• MaxOrderByNodeCount
• MaxSkip
• MaxTop
• PageSize

Зависимый контроллер
Итак, вот примеры простейших запросов REST:

• GET /stations – получить все вокзалы
• GET /trains – расписание всех поездов
• GET /stations/555/arrivals
• GET /stations/555/departures

Допустим, у нас есть вокзал 555, и мы хотим получить все его отправления и прибытия. Очевидно, что здесь должна использоваться сущность, которая зависит от сущности вокзала. Но как это сделать в контроллерах? Если мы все это будет делать роутинг-атрибутами и складывать в один класс, понятно, что в таком примере, как у нас, проблем нет. Но если у вас будет десяток вложенных сущностей и глубина будет расти еще дальше, все это вырастет в неподдерживаемый формат.

И тут есть простое решение — в роутинг-атрибутах в контроллерах можно делать переменные:

[RoutePrefix("stations/{station}/departures")]
public class TrainsFromController : TrainsController
{
  [HttpGet]
  [Route]
  [EnableQuery]
  public IQueryable<TrainTripModel> GetAll(int station)
  {
    return GetAllTrips().Where(x => x.OriginRailwayStationId == station);
  }
}

Соответственно, все зависимые сущности выносите в отдельный контроллер. Сколько их — совершенно неважно, так как они живут отдельно. С точки зрения Web API, они будут восприниматься разными контроллерами — сама система как бы не знает, что они зависимы, несмотря на то, что в URL они выглядят таковыми.

Единственное, возникает проблема — здесь у нас “stations”, и до этого был “stations”. Если вы в одном месте что-то поменяете, а в другом — ничего не поменяете, ничего работать не будет. Однако тут есть простое решение — использование констант для роутинга:

public static class TrainsFromControllerRoutes
{

  public const string BasePrefix = 
    RailwayStationsControllerRoutes.BasePrefix + 
    "/{station:int}/departures";

  public const string GetById = "{id:int}";
}

Тогда зависимый контроллер будет выглядеть так:

[RoutePrefix(TrainsFromControllerRoutes.BasePrefix)]
public class TrainsFromController : TrainsController
{
  [HttpGet]
  [Route]
  [EnableQuery]
  public IQueryable<TrainTripModel> GetAll(int station)
  {
    return GetAll().Where(x => x.OriginRailwayStationId == station);
  }
}

Вы можете делать для зависимых контроллеров простейшие операции — вы просто берете и вычисляете роут сами, и тогда вы не ошибетесь. Кроме того, эти штуки полезно использовать в тестировании. Если вы хотите написать тест и потом хотите этим управлять, а не бегать каждый раз по всем миллионам ваших тестов и исправлять все строки, где указаны эти относительные URL’ы, то вы также можете использовать эти константы. Когда вы их меняете, данные у вас меняются везде. Это очень удобно.

CRUD

Итак, мы с вами обсудили, как могут выглядеть простейшие GET-операции. Все понимают, как сделать единичный GET. Но, кроме него, нам нужно обсудить еще три операции.

• POST – создать новую сущность
  • POST /Stations – JSON-описание сущности целиком. Действие добавляет новую сущность в коллекцию.
  • Возвращает созданную сущность (во-первых, чтобы не было двойных походов к серверу, во-вторых, чтобы, если это нужно, вернуть со стороны сервера параметры, которые посчитались в этом объекте и нужны вам на клиенте).
• PUT — изменить сущность
  • PUT /Stations/12 — Изменить сущность с ID = 12. JSON, который придет в параметре, будет записан поверх.
  • Возвращает измененную сущность. Путь, который был применен много раз, должен приводить систему к одному и тому же состоянию.

• DELETE
  • DELETE /Stations/12 — удалить сущность с ID = 12.

Еще примеры CRUD:

• POST /Stations — добавляем вокзал.
• POST /Stations/1/Departures — добавляем информацию об отправлении с вокзала 1.
• DELETE /Stations/1/Departures/14 — удаляем запись об отправлении с вокзала 1.
• GET /Stations/33/Departures/10/Tickets — список проданных билетов для отправления 10 с вокзала 33.

Важно понимать, что узлы — обязательно какие-то сущности, то, что можно «потрогать» (билет, поезд, факт отправления поезда и т. д.).

Антишаблоны

А вот примеры, как делать не надо:

• GET /Stations/?op=departure&train=11
  Здесь query string используется не только для передачи данных, но и для действий.
• GET /Stations/DeleteAll
  Это реальный пример из жизни. Тут мы делаем GET на этот адрес, и он, по идее, должен удалить все сущности из коллекции — в итоге он ведет себя очень непредсказуемо из-за кэширования.
• POST /GetUserActivity
  На самом деле здесь GET, который записан как POST. POST нужен был из-за параметров запроса в body, но в body у GET нельзя ничего передать — GET можно передать только в query string. GET даже по стандарту не поддерживает body.
• POST /Stations/Create
  Здесь действие указано в составе URL — это избыточно.

Проектируем API

Допустим, у вас есть API, который вы хотите предложить людям, и есть доменная модель. Как связаны сущности API с доменной моделью? Да никак они не связаны, на самом деле. В этом нет никакой необходимости: то, что вы делаете в API, никак не связано с вашей внутренней доменной моделью.

Может возникнуть вопрос, как проектировать API, если это не CRUD? Для этого мы записываем любые действия как команды на изменения. Мы делаем сохранение, чтение, удаление команды, GET, проверку статуса этой команды. GET из коллекции команд — вы получаете список всех команд, которые вы отправляли для какой-либо конкретной сущности.

Доменная модель

Мы поговорим о связи доменной модели с объектами. В примере у нас есть отель (Hotel), есть бронирования (Reservation), комнаты (Room) и устройства (Device), к ним привязанные. В нашем проекте это позволяло управлять комнатами посредством этих устройств.

Но вот незадача: устройство — сущность, которая живет своей жизнью, и непонятно, как ее отделять от отеля. Но разделить отель и устройства, на самом деле, очень просто — поможет DDD. В первую очередь, нужно разобраться, где границы доменных областей и где границы сущностей, ответственных за согласованность системы.

Bounded context (BC)

Bounded context (изолированный поддомен) — фактически, наборы объектов, не зависимые друг от друга и имеющие совершенно независимые модели (разные). В примере мы можем взять и растащить отели и устройства на два разных BC — они не связаны между собой, но присутствует дублирование. Возникает дополнительная сущность (AttachedDevice):

Тут у нас разные представления одного и того же устройства, и в этом нет ничего страшного.

В DDD aggregate route — сущность, которая владеет всеми потомками. Это вершина нашего дерева (Hotel); то, за что можно вытянуть все остальное. А AttachedDevice так взять нельзя — его не существует, и он не имеет никакого смысла. Так же и классы Room и Reservation не имеют никакого смысла, будучи оторванными от Hotel. Поэтому доступ ко всем этим классам — исключительно через рутовую сущность, через Hotel, в данном случае. Device же — другой route с самого начала, другое дерево с другим набором полей.

Итак, если вы понимаете, что одна сущность у вас играет в двух разных доменах, просто распилите ее — и это будет всего лишь проекция мастер-сущности. В AttachedDevice будут, например, поля с номером комнаты, а в Device такие поля не нужны.

А вот примеры запросов, как они могут выглядеть в такой доменной модели:

• PUT /hotels/555/rooms/105/attachedDevices — заменить всю коллекцию привязанных устройств на новую.
• POST /hotels/555/rooms/105/attachedDevices — привязать еще одно устройство.
• DELETE /hotels/12 — удалить описание отеля с ID=12.
• POST /hotels/123/reservations — создать новую резервацию в отеле ID=123.

CQRS — Command Query Responsibility Segregation

Я не буду сейчас рассказывать про это архитектуру, но хочу коротко обрисовать, в чем ее принцип действия. Архитектура CQRS основана на разделении потоков данных.

У нас есть один поток, через который пользователь отправляет на сервер команду об изменении домена. Однако не факт, что изменение действительно произойдет, — пользователь не оперирует данными непосредственно. Итак, после того как пользователь посылает команду на изменение сущности, сервер ее обрабатывает и перекладывает в какую-то модель, которая оптимизирована на чтение — UI считывает это.

Такой подход позволит вам следовать принципам REST очень легко. Если есть команда, значит, есть сущность «список команд».

REST without PUT

В простом CRUD-мире PUT — это штука, которая меняет объекты. Но если мы строго следуем принципу CQRS и делаем все через команды, PUT у нас пропадает, т. к. мы не можем менять объекты. Вместо этого можем лишь послать объекту команду на изменение. При этом можно отслеживать статус выполнения, отменять команды (DELETE), легко хранить историю изменений, а пользователь ничего не изменяет, а просто сообщает о намерениях.

Парадигма REST without PUT — пока еще спорная и не до конца проверенная, но для каких-то случаев действительно хорошо применима.

Fine-grained VS coarse-grained

Представьте, что вы делаете большой сервис, большой объект. Тут у вас есть два подхода: fine-grained API и coarse-grained API («мелкозернистый» и «крупнозернистый» API).

Fine-grained API:

• Много маленьких объектов.
• Бизнес-логика уходит на сторону клиента.
• Нужно знать, как связаны объекты.

Сoarse-grained API:

• Создаете больше сущностей.
• Сложно делать локальные изменения, например
  • POST /blogs/{id}/likes.

• Нужно отслеживать состояние на клиенте.
• Большие объекты нельзя сохранить частично.

Для начала советую проектировать fine-grained API: каждый раз, когда вы создаете объект, отправляете его на сервер. На каждое действие на стороне клиента происходит обращение к серверу. Однако с маленькими сущностями работать проще, чем с большими: если вы напишете большую сущность, вам трудно будет потом ее распилить, трудно будет делать небольшие изменения и выдергивать из нее независимые куски. Т. ч. лучше начинать с маленьких сущностей и постепенно их укрупнять.

Нумерация версий

Так уж сложилось, что к контрактам у нас в отрасли очень расслабленное отношение. Почему-то люди считают, что, если они взяли и сделали API, это их API, с которым они могут делать что угодно. Но это не так. Если вы когда-то написали API и отдали его хоть одному контрагенту, все — это версия 1.0. Любые изменения теперь должны приводить к изменению версии. Ведь люди будут привязывать свой код к той версии, которую вы им предоставили.

На прошлом проекте приходилось несколько раз откатывать API назад просто потому, что он был отдан клиенту — мы поменяли коды ошибок, но клиент уже успел привыкнуть к старым кодам.

Какие известны на текущий момент варианты нумерации версий Web API?

Самое простое — указать версию в URL.

Вот готовые варианты, когда самому ничего делать не надо:

• aspnet.codeplex.com/SourceControl/latest#Samples/WebApi/NamespaceControllerSelector
• aspnet.codeplex.com/SourceControl/latest#Samples/WebApi/RoutingConstraintsSample
• www.strathweb.com/2015/10/global-route-prefixes-with-attribute-routing-in-asp-net-web-api
• github.com/climax-media/climax-web-http

Библиотека Climax.Web.Http

Вот один интересный готовый вариант.

Это всего лишь роутинг атрибутов с constraint — если вы делали какие-либо серьезные объекты, наверняка делали constraint. По номеру версии в этом атрибуте ребята просто реализовали constraint. Соответственно, на один и тот же атрибут с разными версиями, но одинаковым именем контроллера вешаете на два разных класса и указываете разные версии. Все работает «из коробки….

VersionedRoute("v2/values", Version = 2)]<br>
 <br>
 config.ConfigureVersioning(<br>
            versioningHeaderName: "version", vesioningMediaTypes: null);<br>
 <br>
config.ConfigureVersioning(<br>
            versioningHeaderName: null,           <br>
            vesioningMediaTypes: new [] { "application/vnd.model"});<source lang="cs">

<h6><b>Документация</b></h6>
Есть чудесная open-source-штука, имеющая множество различных применений - Swagger. Мы ее используем со специальным адаптером — Swashbuckle. 

<ul>
  <li>http://swagger.io/ </li>
  <li>https://github.com/domaindrivendev/Swashbuckle</li>
</ul> 

Swashbuckle:

<source lang="cs">httpConfiguration
  .EnableSwagger(c => c.SingleApiVersion("v1", ”Demo API"))   .EnableSwaggerUi();


public static void RegisterSwagger(this HttpConfiguration config)
{
  config.EnableSwagger(c =>
  {
    c.SingleApiVersion("v1", "DotNextRZD.PublicAPI")
      .Description("DotNextRZD Public API")
      .TermsOfService("Terms and conditions")
      .Contact(cc => cc
        .Name("Vyacheslav Mikhaylov")
        .Url("http://www.dotnextrzd.com")
        .Email("vmikhaylov@dataart.com"))
             .License(lc => lc.Name("License").Url("http://tempuri.org/license"));
                c.IncludeXmlComme
nts(GetXmlCommentFile());
                c.GroupActionsBy(GetControllerGroupingKey);
                c.OrderActionGroupsBy(new CustomActionNameComparer());
                c.CustomProvider(p => new CustomSwaggerProvider(config, p));
            })
        .EnableSwaggerUi(
c =>
{
  c.InjectStylesheet(Assembly.GetExecutingAssembly(),
    "DotNextRZD.PublicApi.Swagger.Styles.SwaggerCustom.css");
});
        }
}

Как видите, Swagger вытащил все, что у нас есть, вытащил XML-комментарии.

Ниже — полное описание модели GET. Если нажать на кнопку, он ее в самом деле выполнит и вернет результат.

А вот так выглядит документация к POST, первая часть:

Вот вторая часть:

Все, что было написано в XML-комментариях, — здесь.

Источники

• www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
• www.strathweb.com/2015/10/global-route-prefixes-with-attribute-routing-in-asp-net-web-api
• www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling
• jacobian.org/writing/rest-worst-practices
• piwik.org/blog/2008/01/how-to-design-an-api-best-practises-concepts-technical-aspects
• www.toptal.com/api-developers/5-golden-rules-for-designing-a-great-web-api
• www.odata.org
• owin.org
• pietschsoft.com/post/2014/06/15/cqrs-command-query-responsibility-segregation-design-pattern
• blog.pivotal.io/pivotal-labs/labs/api-versioning

Это вторая версия статьи на тему создания REST API с дополнительными комментариями по исходной статье для перевода.

При работе с проектами по интеграции, для получения данных на сайт клиента, в CRM или мобильное приложение из базы данных под управлением MS SQL — реализуем стандартный REST API.

Проще всего создать такую интеграцию используя Node.js и два популярных npm-модуля Express (оснастка веб-сервера) и mssql (MS SQL Server клиент для Node.js).

Сначала создаем таблицы sales и invoices в базе данных SQL-сервера, процедуру для добавления записей в таблицу invoices и заполняем таблицу sales несколькими тестовыми записями:

Проверяем на SQL-сервере созданную таблицу и добавленные тестовые данные:

Переходим к созданию приложения в файле server.js добавляем код.

После сохранения файла server.js проверим работоспособность сервера и выполнения файла скрипта:

node server.js

сервер должен вернуть сообщение о доступности для выполнения запросов, например:

сервер доступен по url http://localhost:8081

Добавим в файл server.js код обработки запроса к web-серверу для получения всех данных из таблицы SQL сервера sales.

Сохраним файл, перезапустим сервер и проверим запрос в Postman, вернется JSON-объект с данными из таблицы SQL-сервера:

Усложняем запрос, добавим в обработчик параметр из URL для выборки по таблице invoices только запись с id = 2.

Передачу значения параметра из URL-запроса реализуем специальным отдельным методом — для исключения проблемы SQL-инъекций.

Результат выполнения запроса, возврат отдельной записи из таблицы в формате JSON:

В следующем обработчике запроса добавим в таблицу “invoices” запись с новым заказом, для REST это должен быть метод HTTP, тип запроса POST :

Для тестирования запросов типа POST требуется установка в браузер дополнения, использования отдельного приложения, например Postman, или же запрос возможно выполнить при помощи curl, используя командную строку:

В результате выполнения запроса получаем json с данными о добавленной записи в таблице invoices. При повторном выполнении новый ID и дата добавления записи.

В результате скрипт приложения server.js следующего содержания:

Дальнейшее дополнение скрипта приложения server.js это — включение в код обработчика ошибок, подключение к SQL через организацию пула соединений, обработка JSON встроенными функциями SQL-сервера.

Ссылка на источник для перевода и корректировки исходного кода статьи. Дополнительная информация по технологиям интеграции систем с использованием MS SQL-сервер — на сайте voInfo.ru.

Почему API называется интерфейсом

Принцип работы API можно представить как общение клиента и сервера. Запрос исходит от клиента, ответ посылает сервер. Например, сервер-метеослужба отправляет данные через API погодным приложениям, которые показывают их на телефоне.

API бывают:

• У операционных систем — так программы получают данные и меняют настройки.
• У языков программирования, чтобы разные функции взаимодействовали корректно.
• В вебе, там они помогают сервисам общаться друг с другом. Если бы все API отключились, сервисы перестали бы работать в ту же секунду.

API считается интерфейсом, потому что скрывает внутреннее устройство взаимодействующих программ. Чтобы вызвать функцию стороннего приложения, не нужно знать, как оно работает. Это упрощает работу: программисту не приходится изучать чужой код, чтобы подключить его функции к своим.

Как работает API

Пользовательский интерфейс предназначен для человека, а API используют приложения. Пользователь вызывает API, который сообщает приложению, что нужно что-то сделать, затем приложение использует API, чтобы тоже попросить веб-сервер что-то сделать. API — это посредник между приложением и сервером. Каждый раз, когда приложение связывается с другим приложением или с сервером, используется API.

Например, посетитель ресторана (пользователь) заказывает у официанта (API) еду с кухни (сервер). Посетителю не нужно знать, как работает кухня, чтобы получить заказ. Можно даже не разбираться в особенностях блюд, достаточно показать на желаемое пальцем.

Приложению не нужно понимать, как работает веб-сервер, достаточно знать, как использовать API для получения данных, необходимых для отображения. А конечному пользователю не нужно понимать, как работают API, достаточно знать, как перемещаться по пользовательскому интерфейсу для выполнения своих задач.

Типы API

REST API

Большинство всех общедоступных API-интерфейсов используют REST из-за его высокой производительности, надёжности и возможности масштабирования.

REST, Representational State Transfer, применяют везде, где пользователю сайта или веб-приложения нужно предоставить данные с сервера. Данные, которые должны быть доставлены, отформатированы в HTML, JSON или XML.

Набор операций — это методы, доступные для HTTP, базовый протокол для того, как браузеры извлекают веб-сайты с серверов. Эти методы включают GET (чтение данных, например получение информации о погоде), POST (создание новых ресурсов, например публикацию сообщения), PUT (для обновления или замены данных), DELETE (для удаления данных).

Запрос REST API состоит из четырёх частей:

• URI — унифицированный идентификатор ресурса, представляющий собой URL-адрес.
• HTTP-метод — чаще всего либо GET, либо POST.
• Headers, которые включают токены аутентификации, определяют формат данных ответа, устанавливают ограничения скорости и выполняют другие административные задачи.
• Body — фактическая часть запроса.

SOAP API

SOAP, Simple Object Access Protocol, немного сложнее, чем REST, потому что требует больше информации о безопасности и о том, как он отправляет сообщения. Более того, данные должны быть написаны на языке XML в соответствии со строгими стандартами, иначе сервер вернёт ошибку.

Корректное SOAP-сообщение состоит из трёх частей:

• Envelope, который определяет XML-документ как сообщение SOAP.
• Header, который содержит атрибуты сообщения.
• Body — сообщение, которое передаёт веб-приложение. Оно может содержать запрос к серверу или ответ от него.

API браузера

Браузер способен создавать широкий спектр пользовательских интерфейсов, таких как воспроизведение музыки, отображение сложных анимаций, реакция на ввод с помощью мыши или клавиатуры. Браузер предоставляет веб-разработчикам контроль над этими возможностями через API браузера, использующие JavaScript для манипулирования HTML.

iOS и Android API

Подобно API-интерфейсам браузера, каждая мобильная платформа имеет набор API-интерфейсов, который предоставляет разработчикам инструменты создания возможностей для пользователей. Разработчики приложений используют эти API для передачи данных на устройства, использования камеры, воспроизведения музыки или выполнения других функций.

Как вызвать API

Напрямую система может вызывать как функции внутри себя, так и методы другой программы. Во втором случае приложение может отправить запрос на получение данных из другого приложения. Метод также вызывают вручную, чтобы протестировать работоспособность системы, не трогая графический интерфейс.

Косвенный вызов API производит пользователь, работая с графическим интерфейсом. Например, щёлкая по кнопке «Создать новую вкладку» в браузере, пользователь вызывает в API функции, результат которых — появление новой вкладки.