Что такое сервер api. Серверная платформа API. Error - сведения об ошибке

6.1 Метод CheckDimensions

Синтаксис:

Boolean CheckDimenshions (Dimensions DimensionsList,

Out float Length,

Out float Width,

Out float Height,

Out float Weight,

Out string Comment)

Параметры:

Имя параметра	Входной / Выходной	Тип	Описание
DimensionsList	входной	Dimensions	Массив габаритно­весовых характеристик товаров
Length	выходной	float	Длина посылки
Width	выходной	float	Ширина посылки
Height	выходной	float	Высота посылки
Weight	выходной	float	Вес посылки
Comment	выходной	float	Текстовое описание при превышении предельных значений габаритно­весовых характеристик

Описание:

В метод передается список габаритно­весовых характеристик всех товаров
(DimensionsList). После расчета выходные параметры Length, Width, Height (длина,
ширина и высота соответственно) заполняются габаритами посылки, после решения
задачи «оптимальной укладки», а в параметр Weight передается суммарный вес всех
товаров, без учета упаковочных материалов. В том случае если габариты отправления
превышают предельные значения в параметр Comment передается текстовое описание
несоответствия.

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

6.1.1 Пример вызова метода CheckDimensions

// Предположим, что в корзине 2 позиции и необходимо проверить не превышают ли он
ограничения по допустимым габаритам и весу
aplix.Dimensions Dimensions = new aplix.Dimensions;
aplix.Dimensions Item;

Item.Length = 0.130f;
Item.Width = 0.100f;
Item.Height = 0.001f;
Item.Weight = 0.1f;
Item.Qty = 2;
Dimensions = Item;
Item = new aplix.Dimensions();
Item.Length = 0.1331f;
Item.Width = 0.0998f;
Item.Height = 0.0788f;
Item.Weight = 0.575f;
Item.Qty = 1;
Dimensions = Item;
// Выходные параметры
float Length;
float Width;
float Height;
float Weight;
string Comment;
// Выполнить проверку габаритно‐весовых характеристик
bool Result = ws.CheckDimenshions(Dimensions, out Length, out Width, out Height, outWeight, out Comment);
// Визуализация результата
Response.Write("Result:" + Result.ToString() + "");
Response.Write("Length:" + Length.ToString() + "");
Response.Write("Width:" + Width.ToString() + "");
Response.Write("Height:" + Height.ToString() + "");
Response.Write("Weight:" + Weight.ToString() + "");
Response.Write("Weight:" + Comment + "");

6.2 Метод CalculateShippingCost

Синтаксис:
Long CalculateShippingCost (string OrderNumber,
Float DeclaredCost,
Goods Goods,
Address Address,
Byte TypeOfSeal,
Boolean SturdyPackaging,
Boolean CashOnDelivery,
Out DeliveryType Types,
Out string Comments)Параметры:

Имя параметра	Входной / Выходной	Тип	Описание
OrderNumber	входной	string	Номер заказа, если известен в системе потребителя. Если будет задан, то расчет в будущем будет привязан к заказу.
DeclaredCost	входной	Float	Объявленная ценность отправления. На страховка.
Goods	входной	Goods	Список товаров массив структур (Артикул, Наименование, Длина, Ширина, Высота, Вес, Количество)
Address	входной	Address	Адрес получателя (структура: Почтовый индекс, Регион, Район, Город, Населенный пункт, Улица, Дом, Корпус, Картира)
TypeOfSeal	входной	Byte	Вариант уплотнения, возможные значения:1 ­Не требуется 2 ­Пузырчатая пленка 3­ Наполнитель
SturdyPackagin	входной	Boolean	Обязательно ли требуется жесткая упаковка
CashOnDelivery	входной	Boolean	Требуется ли наложенный платеж
Types	выходной	DeliveryType
Comments	выходной	DeliveryType	Список доступных вариантов доставки

Описание:

Метод по заданным параметрам выдает список доступных вариантов доставки
(выходной параметр Types) в виде массива структур <Идентификатор способа доставки, Наименование способа доставки, Себестоимость доставки, Страховую премию, Затраты на упаковку и маркировку, Адрес нахождения почтового отделения, либо точки самовывоза, Режим работы почтового отделения, либо точки самовывоза, Минимальное количество дней доставки, Максимальное количество дней доставки, Доп.информация>. Если в процессе расчета возникли какие­либо исключения, то
описание ошибки будет возвращено в параметр Comments.

Возвращаемое значение:

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

6.2.1 Пример вызова метода CalculateShippingCost

ws.Credentials = new NetworkCredential("test", "test");


Address.Index = "684005";


Address.City = "Елизово г";

Address.Home = "16";


aplix.Goods Item;
Item = new aplix.Goods();
Item.SKU = "216293";

Item.Length = 0.130f;
Item.Width = 0.100f;
Item.Height = 0.001f;
Item.Weight = 0.1f;
Item.Qty = 2;
Goods = Item;
Item = new aplix.Goods();
Item.SKU = "499687";

Item.Length = 0.1331f;
Item.Width = 0.0998f;
Item.Height = 0.0788f;
Item.Weight = 0.575f;
Item.Qty = 1;
Goods = Item;
//Заполним параметры для калькулятора
string OrderNumber="1234567890";
float DeclaredCost = 36370;
sbyte TypeOfSeal = 1;
bool SturdyPackaging = true;
bool CashOnDelivery = false;
aplix.DeliveryType Types; string Comments;
//Вызов калькулятора
long Status = ws.CalculateShippingCost(OrderNumber, DeclaredCost, Goods, Address,TypeOfSeal, SturdyPackaging,CashOnDelivery, out Types, out Comments);
//Визуализация результата
Response.Write("Id расчета:"+Status.ToString()+"
");
Response.Write("Доп.информация по расчету:" + Comments + "
");
Response.Write(@"
");
foreach (aplix.DeliveryType type in Types) {
Response.Write(""+ " "+ " "+ " " + " " + " " + " " + " " + " " + " " + " " + " " + " " + " "); }
Response.Write("

TypeId	TypeName	TypeDescription	Cost	Insurance	PostalRate	PreparingCost	Address	Worktime	MinPeriod	MaxPeriod	AdditionalInformation
" + type.TypeId.ToString() + "	" + type.TypeName + "	" + type.TypeDescription + "	" + type.Cost.ToString() + "	" + type.Insurance.ToString() + "	" + type.PostalRate.ToString() + "	" + type.PreparingCost.ToString() + "	" + type.Address + "	" + type.Worktime + "	" + type.MinPeriod.ToString() + "	" + type.MaxPeriod.ToString() + "	" + type.AdditionalInformation + "

");

 }


6.3 Метод PushOrder

Синтаксис:


     Long PushOrder
(

           ID,

           Number,

           Date,

           Customer,

           DeclaredCost,

           AmountToBePaid,

           DeliveryTypeId,

           TypeOfSeal,

           SturdyPackaging,

           Activity,

           Goods,

           DeliveryDate,

           StartTimeDelivery,

           EndTimeDelivery,

           Сomment,

           ShipperId,

           Marker)
Параметры:

Имя параметра

Входной / Выходной

Тип

Описание

ID

входной

String


Идентификатор заказа в системе

потребителя (уникальное значение)

Number

входной

String


Номер заказа в системе потребителя

(будет распечатываться в комментариях

при маркировке отправлений)

Date

входной

DateTime


Дата заказа в системе потребителя (будет

распечатываться в комментариях при

маркировке отправлений

Customer

входной

Customer


Информация о покупателя, струкутра

DeclaredCost

входной

Float


Объявленная ценность отправления. На

указанную сумму будет оформленная

страховка.

AmountToBeP

aid

входной

Float


Сумма

к

оплате.

Если

заказ

предоплаченю то 0.

DeliveryTypeId

входной

Int


Идентификатор выбранного способа

доставки.

TypeOfSeal

входной

Int


Вариант

уплотнения,

возможные

значения:

1­Не требуется

2­Пузырчатая пленка

3­Наполнитель

SturdyPackaging

входной

Boolean


Обязательно ли требуется жесткая

упаковка

Activity

входной

Boolean


Актуальность заказа. True – если заказ

актуален, False – если заказ отменен.

Goods

входной

Goods


Список товаров

DeliveryDate

входной

DateTime


Дата доставки, заполняется если выбрана

 курьерская доставка

StartTimeDeliv

ery

входной

Int


Желаемое

 время

 доставки

 «С»,


 доставка

EndTimeDelivery

входной

Int


Желаемое время доставки «До»,

 заполняется если выбрана курьерская

 доставка

Сomment

входной

String


Комментарий к заказу

ShipperId

входной

String


Идентификатор

 отправителя,

 заполняется

 если

 у контрагента

 несколько интернет магазинов

Marker

входной

String


Маркер заказа, заполняется если

 отправления маркируются метками

 сайт

Описание:


Метод размещает информацию о заказе в системе исполнителя. Система­потребитель

передает номер и дату заказа, уникальный идентификатор заказа, информацию о

получателе, включая его адрес и телефон, объявленную ценность, сумму наложенного

платежа если таковая есть, состав товарного вложения, тип упаковки и выбранный

способ и детали доставки.
Возвращаемое значение:


Метод возвращает уникальный идентификатор заказа в системе исполнителя.
6.3.1 Пример вызова метода PushOrder



aplix.Delivery ws = new aplix.Delivery();

 ws.Credentials = new NetworkCredential("test", "test");

 // Подготовим струкутру "Получатель отправления"

 aplix.Customer Customer = new aplix.Customer();

 // 684005, Камчатский край, Елизовский р‐н, Елизово г, Ленинская ул, дом No 16

 aplix.Address Address = new aplix.Address();

 Address.Index = "684005";

 Address.Region = "Камчатский край";

 Address.District = "Елизовский р‐н";

 Address.City = "Елизово г";

 Address.Street = "Ленинская ул";

 Address.Home = "16";

 Customer.Address = Address;

 Customer.ID = "[email protected]";

 Customer.Name = "Сергей";

 Customer.Email = "[email protected]";

 Customer.Phone = "+7(916)975‐53‐54";

 //Заполним параметры заказа

 string ID = "2013‐1234567890"; // Уникальный идентификатор заказа в системе клиента

 string Number = "1234567890"; // Номер заказа в системе клиента

 DateTime Date = new DateTime(2013, 08, 30);

 float DeclaredCost = 36350.0f; // Объявленная ценность

 float AmountToBePaid = 0; // Нет наложенного платежа

 int DeliveryTypeId = 4; // ЕМС

 sbyte TypeOfSeal = 2; // Пузырчатая пленка

 bool SturdyPackaging = true; // Жесткая упаковка (для хрупких вещей)

 bool Activity = true; // Документ актуален

 // Предположим, что заказ состоит из 2 позиций

 aplix.Goods Goods = new aplix.Goods;

 aplix.Goods Item;

 Item = new aplix.Goods();

 Item.SKU = "216293";

 Item.Name = "карта памяти SDXC 64Gb Class 10 Transcend";

 Item.Length = 0.130f;

 Item.Width = 0.100f;

 Item.Height = 0.001f;

 Item.Weight = 0.1f;

 Item.Qty = 1;

 Item.Price = 2080.0f;

 Item.VATRate = "НДС18";

 Goods = Item;

 Item = new aplix.Goods();

 Item.SKU = "499687";

 Item.Name = "зеркальный фотоаппарат Canon EOS 650D Kit Tamron AF 18‐270mm Black";

 Item.Length = 0.1331f;

 Item.Width = 0.0998f;

 Item.Height = 0.0788f;

 Item.Weight = 0.575f;

 Item.Qty = 1;

 Item.Price = 34270.0f;

 Item.VATRate = "НДС18";

 Goods = Item;

 DateTime DeliveryDate = new DateTime(2013, 09, 05); //Доставка на 05 09 2013 года

 int StartTimeDelivery = 10; // интервал доставки с 10

 int EndTimeDelivery = 14; // до 14

 string Comment = "Тестовый заказ";

 //Впулить заказ в систему

 long OrderId = ws.PushOrder(ID, Number, Date, Customer, DeclaredCost, AmountToBePaid,DeliveryTypeId, TypeOfSeal, SturdyPackaging, Activity, Goods, DeliveryDate, StartTimeDelivery,EndTimeDelivery, Comment, "", "");

 Response.Write("Id заказа:" + OrderId.ToString() + "

");


6.4 Метод GetDetailsOfCost

Синтаксис:
        DetailsOfCostList GetDetailsOfCost (ID, TypeId) Параметры:

Входной / Выходной

Тип

Описание
входной

Long

Идентификатор расчета (уникальное значение), полученный при вызове метода CalculateShippingCost
входной

Int

Имя параметра

ID

TypeId

Описание:
 Метод возвращает детализированный список затрат на маркировку и упаковку отправления по заданным идентификатору расчета и идентификатору варианта доставки. Возвращаемое значение:
 Метод возвращает массив структур


Каждый элемент массива содержит описание затраты, количество, цену и стоимость.
6.4.1 Пример вызова метода GetDetailsOfCost



 aplix.Delivery ws = new aplix.Delivery();

 ws.Credentials = new NetworkCredential("test", "test");

 long ID = 168; // Идентификатор расчета, полученный методом CalculateShippingCost

 int TypeId = 3; // Почтовая доставка


 aplix.DetailsOfCost Details = ws.GetDetailsOfCost(ID, TypeId);

 //Визуализация результата

 Response.Write("Id расчета:" + ID.ToString() + "

");

 Response.Write("Id метода доставки:" + TypeId.ToString() + "

");

 Response.Write(@"

");
foreach (aplix.DetailsOfCost DetailOfCost in Details)
{
Response.Write("" + " " + " " + " " + " " + " ");
}
Response.Write("

Description	Price	Qty	Cost
" + DetailOfCost.Description + "	" + DetailOfCost.Price.ToString() + "	" + DetailOfCost.Qty.ToString() + "	" + DetailOfCost.Cost.ToString() + "

");


6.5 Метод PushReestr

Синтаксис:
 Long PushOrder (ID, Number, Date, DateOfShipment, IDs) Параметры:

Входной / Выходной

Тип

Описание
входной

String

Идентификатор реестра в системе потребителя (уникальное значение)
входной

String

Идентификатор варианта доставки, по которому необходимо получить детализацию
входной

DateTime

Дата реестра (будет распечатываться в актах приема­передачи отправлений)
входной

DateTime

Ожидаемая дата передачи отправлений исполнителю
входной

String

Массив идентификаторов заказов, которые включаются в данный реестр
Имя параметра

ID

Number

Date

DateOfShipment

IDs

Описание:
 Метод размещает информацию о реестре в системе исполнителя. Система­потребитель передает номер и дату реестра, уникальный идентификатор реестра, ожидаемую дату передачи отправлений исполнителю. Возвращаемое значение:
 Метод возвращает уникальный идентификатор реестра в системе исполнителя.
6.5.1 Пример вызова метода PushReestr



 aplix.Delivery ws = new aplix.Delivery();

 ws.Credentials = new NetworkCredential("test", "test");

 // Список идентификаторов заказов, которые входят в данный реестр

 string IDs={"2013‐1234567890", "2013‐1234567891"};

 // Уникальный идентификатор реестра в системе клиента

 string ID = "2013‐r12345";

 // Номер реестра в системе клиента

 string Number = "r12345";

 // Дата формирования реестра в системе клиента

 DateTime Date = new DateTime(2013, 10, 22);

 // Предполагаемая дата передачи заказов на доставку

 DateTime DateOfShipment = new DateTime(2013, 10, 23);

 // Получим детализацию расчета

 long ReestID = ws.PushReestr(ID, Number, Date, DateOfShipment, IDs);

 //Визуализация результата

 Response.Write("Id реестра:" + ReestID.ToString() + "

");


6.6 Метод GetTrackNumbers

Синтаксис:
 DateTime GetTrackNumbers
 (DateOfLastGetting, TrackNumbers) Параметры:

Входной / Выходной

Тип

Описание
входной

DateTime

Дата последнего успешного получения трек­номеров. Параметр используется для того чтобы сократить объем передаваемых данных и не дублировать данные, которые были выгружены ранее.
входной

TrackNumber

Массив трек­номеров по заказам
Имя параметра

DateOfLastGetting

TrackNumbers

Описание:
 Метод возвращает список трек­номеров, которые были привязаны к заказам за период с DateOfLastGetting по текущее время. Результата помещается в выходной параметр TrackNumbers. Свойство Activity имеет значение true, если трек­номер актуален, иначе ложь. Возможны ситуации, когда отправлению присваивается один трек­номер, а по истечении некоторого второй трек номер, в этом случае трек­номер, присвоенный изначально становиться не актуальным. Возвращаемое значение:
 Метод возвращает дату и время на которое актуальны выгружаемые данные. Данное значение необходимо использовать при следующем вызове метода GetTrackNumbers в параметре DateOfLastGetting.
6.6.1 Пример вызова метода GetTrackNumbers



 aplix.Delivery ws = new aplix.Delivery();

 ws.Credentials = new NetworkCredential("test", "test");

 // Дата последнего удачного получения треков

 DateTime DateOfLastGetting = new DateTime(2013, 08, 01);

 aplix.TrackNumber TrackNumbers;

 // Получим список трек‐номеров

 DateTime NewDateOfLastGetting = ws.GetTrackNumbers(DateOfLastGetting, out TrackNumbers);

 //Визуализация результата

 Response.Write("NewDateOfLastGetting: " + NewDateOfLastGetting.ToString() +"

");

 Response.Write(@"

");
foreach (aplix.TrackNumber TrackNumber in TrackNumbers)
{
Response.Write("" + " " + " " + " " + " ");
}
Response.Write("

OrderID	TrackNumber	Activity
" + TrackNumber.OrderID.ToString() + "	" + TrackNumber.Number + "	" + TrackNumber.Activity+ "

");


API Server принимает все API-запросы от внешних приложений. Для проверки подлинности пользователей, API Server использует систему аутентификации, аналогичную системе шифрования открытым ключом (public-key encryption).
Криптографическая система с открытым ключом (или асимметричное шифрование, асимметричный шифр) - система шифрования и/или электронной цифровой подписи (ЭЦП), при которой открытый ключ
 передаётся по открытому (то есть незащищённому, доступному для наблюдения) каналу и используется для проверки ЭЦП и для шифрования сообщения. Для генерации ЭЦП и для расшифровки сообщения используется секретный ключ
.
Все запросы к API Server осуществляются на файл фронт-контроллера. Именно в этом файле происходит идентификация открытого и секретного ключей.
Вот пошаговое описание этого процесса:
На сервер по адресу расположения файла фронт-контроллера приходит запрос от API клиента. В запросе содержатся APP ID (открытый ключ клиента) и APP KEY (32-символьная, шифрованная с помощью секретного ключа клиента строка). Секретный ключ никогда не отправляется на сервер, он используется только для шифрования запроса. В запросе содержатся параметры вызова сервера – пользователь, пароль доступа, название контроллера и действия, которое должно обработать вызов клиента. Например, массив параметров может выглядеть так:
 $items = array("controller" => "todo",
"action" => "read",
"username" => $username,
"userpass" => $userpass);
Когда на API Server приходит запрос, сервер проверяет список приложений на наличие открытого ключа (APP ID);
Если открытый ключ не найден – выбрасывается исключение типа «Request is not valid». Если ключ имеется, сервер берет секретный ключ, который соответствует этому открытому ключу, и пытается расшифровать пришедший запрос;
Если расшифровка была успешной, из пришедшего запроса вытягиваются и обрабатываются параметры controller и action. Фронт-контроллер, который обрабатывает запрос, подключает нужный файл контроллера и вызывает действие, содержащееся в параметре action;
В случае успеха/неудачи обработки запроса клиент получает ответ от API Server.

API (Application Programming Interface) — это определенное представление данных для взаимодействия между приложениями. В частном случае, в качестве ответного приложения, может выступать сервер. АПИ — это описанный формат, которому должны соответствовать обе стороны обмена данными.
Технология различных API — это набор методов взаимодействия. Система АПИ в том или ином виде представлена везде. Например, у нас в руках смартфон с приложением покупки билетов. На самом «высоком» уровне мы видим графическую часть приложения с полями ввода данных. Мы запрашиваем рейсы по маршруту на определенный день и что в этот момент происходит:
Мобильное приложение формирует запрос к серверу. Запрос формируется в определенном формате. Например: Вылет:МоскваDME,Прилет:АмстердамAMS,Дата:01-01-2017,Мест:2,Класс:Эконом. Эта строчка содержит строгий формат — Заголовок:Значение, все значения через запятую, обязательные поля Вылет, Прилет и Дата, если не указаны другие данные, то они будут по-умолчанию: Мест:1, Класс:Эконом.
Сервер авиакомпании получает этот запрос и программа понимает, что от нее требуется найти рейсы и цены.
Сервер обращается к базе данных на языке SQL, что тоже является частным представлением API
База данных обращается к файлу через API файловой системы
Файловая система обращается к жесткому диску — через его API-протокол.
Можно продолжить углубление, но и так понятно, что любая задача программирования — это выстраивание иерархии API.
Сегодня в том или ином виде, вся информация в компьютерном виде представляется посредством АПИ.
Мы разрабатываем системы API для высшего уровня, где следующим потребителем является клиентское приложение.
Классификация видов АПИ
В зависимости от решаемой задачи, протоколы передачи АПИ могут быть как стандартизированные, так и собственного формата. Наиболее часто применяются стандартизированные протоколы, это позволяет разработчикам задействовать готовые модули для их обработки, что сокращает время на разработку приложения. Различные специфические типы применяются для достижения определенного преимущества, например снижения трафика, скорость распознавания команд, а в некоторых случаях — это единственная возможность — разработка собственного формата — к примеру вещание видео с эфимеридной составляющей.
По виду передаваемой информации АПИ подразделяется на следующие форматы:
Стандартные протоколы API
Текстовый

Бинарный
Поточный
Кадровый

По виду взаимодействия клиент-сервер, наиболее распространены следующие виды:
Пакетные
HTTP/HTTPS
Sockets

Процедурные (протокольные)

Поточные
Широковещательные
Применение систем АПИ
Все онлайн-сервисы и системы имеют публичные API. В некоторых случаях за использование доступа к API приходится оплатить подписку или определенное количество обращений. Если в Ваших целях стоит создание онлайн-сервиса, который будет предоставлять какую-либо информацию, обратите на API особенное внимание. Подход и хорошее документирование возможностей API, это ключ к успеху. Все сторонние разработчики, которые в последующем будут создавать дополнительные приложения, обязаны использовать именно этот протокол.
Довольно частая практика, когда сервер API, это единственное представление данных всего сервиса, а клиентская часть работает только через приложение. Яркие примеры Viber, Instagram, Swarm- еще эти приложения называют Mobile only (только в мобильном). В связи с этим, должна быть создана система распределения нагрузки между серверами API, что позволит создать сервис 24/7 при масштабируемой мощности. Перед созданием серверной части, следует сразу оценить возможности данного мероприятия и учитывать эти возможности при разработке программ.
Для достижения стабильности, преимущественно применяются разработки под Linux-среду и его системные сервисы. Это обуславливается тем, что эта операционная система более гибкая, ресурсоемкая и имеет высокий уровень журналирования и отладки при сбоях. В качестве публикатора применяются веб-серверы или специальные сервисы. Мы имеем ряд наработок многопоточных сервисов для обеспечения систем API.
Мы описали, как это работает, давайте взглянем, как на этом зарабатывать? Первый метод напрашивается сам собой — предоставление услуги через АПИ. Вы можете продавать услуги или товары напрямую — обращение к АПИ Вашего ресторана, сформирует заказ на доставку еды на дом. Или предоставлять полезный сервис на платной основе, например формирование бухгалтерских отчетов.
Второй метод заработка на АПИ заключается в аггрегировании нескольких систем в один сервис. Мы уже обсудили вид АПИ для авиакомпании, но авиакомпаний десятки, а то и сотни. Сейчас стали популярны сервисы по продаже билетов — Aviasales, OneTwoTrip, Momondo, которые фактически из себя ничего не представляют, а только берут разные АПИ от авиакомпаний и публикуют собственный сервис, который собирает данные с этих компаний. Практика очень распространенная и высокодоходная.
Третий метод заработка на API, это «подмешивание данных». Если опять вернемся к авиакомпании, то мы можем создать сопутствующую услугу на их базе, к примеру, страхование. Мы публикуем сервис или альтернативную точку входа АПИ, где помимо рейсов, в данные АПИ будет добавлена информация по страхованию с привязкой к конкретному рейсу. Также поступают, к примеру, авиакомпании или посредники, расширяя АПИ для информирования об отелях.
Создание технологий АПИ
Мы предлагаем свои услуги по созданию серверов API всех описанных ранее типов и протоколов. Мы имеем опыт построения взаимодействия в различных высоконагруженных системах. На выходе мы представляем не только готовый сервер (черный ящик) но и полное описание протокола в виде конструкторской документации. Данное описание протокола может быть предоставлено следующим разработчикам, применяемым эти данные, либо в открытом доступе для OpenSource.
Помимо непосредственно сервера, мы можем создать систему слежения и аналитики, которая будет сигнализировать об ошибках и превышением регламентированной нагрузки сервера(-ов).
API (от англ. Application Program Interface) – это интерфейс взаимодействия между сайтом клиента и сервером. Представляет собой ресурс, который сервер открывает для работы извне, т.е. программист может воспользоваться им для получения доступа к функционалу программы, библиотеки, модуля. API делает возможным работу ресурсов, которые используют потенциал и мощность предоставляющего сайта, а также запуск дополнительных компонентов к ним, расширяющих возможности web-проекта.
Преимущества:
Типы

возвращающие. На запрос стороннего приложения какого-либо метода с заданными параметрами сервер дает запрашиваемую информацию в определенном формате;
 
изменяющие. Клиент вызывает некоторую функцию сервера, которая вводит новую информацию или изменяет на нем определенные настройки.
API Яндекс.Директа
Для продвижения сайтов эффективен API .
На его базе разработчики могут создавать приложения, которые напрямую взаимодействуют со службой поисковой системы. Такие программы позволят рекламодателям гибко управлять масштабными , получать статистические отчеты по каждой из них, точно прогнозировать бюджеты.
 
Рекламные агентства с помощью API Директа могут просмотреть весь список своих клиентов, клиенты – представителей.
 
Если определенные фразы, используемые для поисковой оптимизации , дают низкий CTR в контекстной рекламе, показ по ним можно автоматически отключить. На тематических площадках через API можно задавать ставки, определенные доноры могут быть удалены.
 
API Яндекс.Директа имеет SOAP-интерфейс, т.е предоставляет широкий выбор языков программирования для создания приложений. Данный протокол поддерживается такими языками, как Perl, Java,
Работая с API, можно испытывать одновременно радость и разочарование. С одной стороны, взаимодействуя с другими приложениями, вы можете сильно увеличить охват аудитории и "вау-эффект" вашего приложения. С другой, это включает в себя чтения тонны документации, изучение стратегий аутентификации и разбор неинформативных (или даже отсутствующих) сообщений об ошибках.
Прежде всего, если вы до сих пор не до конца понимаете, что же такое API (Application Programming Interface - интерфейс программирования приложений), прочтите объяснение от Skillcrush , а затем первую часть этой статьи , чтоб наверстать упущенное.
"API" невероятно обширная концепция - каждый раз, когда ваше приложение "общается" с другим приложением, это происходит через некий API. Компоненты внутри вашего собственного приложения, вроде разных частей Rails, также общаются друг с другом через API. Они являются более или менее независимыми субприложениями, которые передают данные, необходимые каждому из них для выполнения собственных специфических задач. В мире приложений все является API!
Когда вы создаете приложения с более динамической фронтенд-функциональностью (как одностраничные Javascript-приложения, так и простые приложения с отдельными AJAX-вызовами), они будут общаться с Rails-бэкендом через ваш собственный API, который в действительности просто дополнительная пара-тройка строк кода, говорящая вашим контроллерам, как отдать JSON или XML вместо HTML.
В этом уроке вы изучите как создать свой собственный API. В последующих уроках мы осветим как взаимодействовать с API других приложений. Уроки должны стать хорошим трамплином для изучения этой темы, но вряд ли смогут полностью охватить все случаи. Большая часть работы с API - это умение читать их документацию и разбираться, чего они от вас хотят.
Пункты для размышления
Просмотрите вопросы и проверьте, знаете ли на них ответы. Проверьте себя снова после выполнения задания.

Как Rails понимает, какой тип файла вы ожидаете в ответ, когда посылаете HTTP-запрос.
В чем заключается цель метода #respond_to ?
Как вернуть объект пользователя (User), при этом указать атрибуты, которые не хотите включать в этот объект (то есть, вы не можете просто вернуть User.first)?
Назовите 2 шага, выполняемых "за кулисами" метода #to_json .
Как указать действию контроллера, что требуется рендерить лишь сообщение об ошибке?
Как создать свое собственное сообщение об ошибке?
Почему вы не можете использовать методы аутентификации контроллера, основанные на сессиях, если хотите позволить программно подключаться к вашему API?
Что такое "Сервис-ориентированная архитектура"?
Основы API
Ваше Rails-приложение на самом деле уже является API, хотя вы могли не думать о нем как об API. Веб-браузер, запускаемый вашими пользователями, также является программой, так что он фактически отправляет API-запрос вашему Rails-приложению, когда пользователь открывает новую страницу. Мы привыкли так думать потому, что рендеринг HTML-шаблонов настолько распространенная задача, что мы просто зашиваем этот функционал в наши серверные программы в качестве стандартного типа ответа, и все остальное считаем чем-то необычным.
Однако, часто вы хотите сделать запрос, который не требует переживать все головные боли от использования браузера. Вас может не заботить структура страницы (HTML), но взамен вы хотите получить чистые данные. Допустим, вы хотите получить список всех пользователей. Вы можете запросить что-то вроде http://yourapplication.com/users , что наверняка запустит действие #index и отрендерит список всех пользователей приложения.
Но зачем заморачиваться со всей этой лишней информацией, если все чего вы хотите - это получить список пользователей? Самым простым вариантом будет отправить запрос на тот же самый URL, указав ожидание JSON или XML ответа взамен. Если вы правильно настроите ваш Rails-контроллер, назад вы получите простой JSON объект-массив, содержащий всех пользователей. Прекрасно!
Тот же самый принцип применяется, когда вы общаетесь с внешним API. Скажем, вы хотите получить недавние "твиты" пользователя из Twitter. Вам потребуется лишь сообщить вашему Rails-приложению как взаимодействовать с API Twitter"а (т.е. аутентифицировать себя), отправить запрос и обработать набор "твитов", который будет возвращен.
Создание API
Вы можете захотеть сделать ваше Rails-приложение чистым бэкенд API для фронтенд веб-страниц, или просто захотите научиться посылать JSON, когда фронтенд запрашивает его. Этот раздел не осветит как создавать полноценные RESTful API с функциями аутентификации. Это плавное введение в обращение с вашим приложением как с API.
Основы
Если вы хотите, чтобы ваше Rails-приложение возвращало JSON вместо HTML, вам потребуется сказать вашему контроллеру, чтобы он это делал. Самое замечательное то, что одно и то же действие контроллера может возвращать различные типы в зависимости от того, делает ли ваш пользователь обычный запрос из браузера или обращается к API через командную строку. Это определяет какой тип запроса был сделан, основываясь на расширении запрашиваемого файла, например, example.xml или example.json .
Вы можете проверить, что Rails "думает" об ожидаемом вами типе файла, проверив серверный лог:
Started GET "/posts/new" for 127.0.0.1 at 2013-12-02 15:21:08 -0800
 Processing by PostsController#new as HTML
Первая строка говорит вам какой URL был запрошен, а вторая сообщает куда он был направлен и как Rails его обрабатывает. Если бы вы использовали расширение.json , то это выглядело бы так:
Started GET "/posts.json" for 127.0.0.1 at 2013-12-04 12:02:01 -0800
 Processing by PostsController#index as JSON
Если у вас есть запущенное тестовое приложение, попробуйте запросить различные URL. Если ваш контроллер не умеет их обрабатывать, то вы можете получить ошибку, но все равно должны видеть, что Rails понимает под вашими запросами.
Рендеринг JSON или XML
Когда вы решите, что хотите отвечать на запросы с помощью JSON или XML, вам потребуется сообщить вашему контроллеру, что нужно рендерить JSON или XML вместо HTML. Один из способов сделать это - использовать метод #respond_to:
Class UsersController < ApplicationController
 def index
 @users = User.all
 respond_to do |format|
 format.html # index.html.erb
 format.xml { render xml: @users }
 format.json { render json: @users }
 end
 end
 end
В данном случае, #respond_to передает в блок объект формата, к которому вы можете приложить соответствующий вызов рендеринга. Если вы ничего не сделаете, будет рендериться html с использованием стандартного Rails-шаблона (в этом примере app/views/index.html.erb).
Функция #render достаточно умна, чтобы понять, как рендерить широкий спектр форматов. Когда вы передаете ей ключ:json , она вызовет #to_json на значении, в данном примере на @users . Это преобразует ваш(и) Ruby-объект(ы) в JSON-строки, которые будут переданы запрашивающему приложению.
Таким образом, вы получаете свой API. Конечно, создание API может быть немного более сложным, если вы захотите делать какие-то необычные вещи, но все держится на основах.
Указание возвращаемых атрибутов
Допустим, вы хотите убедиться, что не возвращаете email-адрес пользователя вместе с объектом пользователя (User). В этом случае, вы захотите изменить атрибуты, которые будут возвращаться, модифицируя то, что делает метод #to_json .
Раньше вы бы просто переопределили метод #to_json своей версией, но теперь вам это не понадобится - в действительности, вы взамен переопределите метод #as_json . Метод #as_json используется в методе #to_json , так что его модификация неявно изменён результат #to_json , но довольно специфическим способом.
#to_json делает 2 вещи: запускает #as_json и получает хэш атрибутов, которые будут отрендерены в JSON. Затем он проводит рендеринг в JSON, используя ActiveSupport::json.encode . Так что, модифицируя #as_json , вы более конкретно указываете ту часть метода #to_json , которую в действительности хотите изменить.
В нашем случае, мы делаем это модифицируя #as_json в нашей модели так, чтобы возвращать лишь необходимые нам атрибуты:

 # app/models/user.rb
 class User < ActiveRecord::Base
 # Вариант 1: Полное переопределение метода #as_json
 def as_json(options={})
 { :name => self.name } # НЕ включаем поле email
 end
 # Вариант 2: Используем стандартный метод #as_json
 def as_json(options={})
 super(only: [:name])
 end
 end
Затем, в нашем контроллере лишь потребуется отрендерить JSON как обычно (в примере ниже всегда будет возвращаться JSON, независимо от того, был ли отправлен HTML-запрос или нет):

 # app/controllers/users_controller.rb
 class UsersController < ApplicationController
 def index
 render json: User.all
 end
 end
Заметьте, что вам не нужно самостоятельно вызывать #to_json , когда вы используете #render - он сделает это за вас.
Иногда Heroku может потребовать дополнительные шаги для корректного отображения ваших страниц с ошибками. Посмотрите . Вам может потребоваться сперва удалить статичные страницы из директории app/public .
Обеспечение безопасности извне
Допустим, вы хотите позволить обращаться к API только если пользователь залогинен. Ваша существующая аутентификация в контроллере уже делает эту работу - просто убедитесь, что у вас установлен правильный #before_action (например, before_action:require_login). Может потребоваться функционал, когда и залогиненный и не залогиненный пользователи могут просматривать страницу, но каждый должен видеть различные данные. Вы не хотите, чтобы незалогиненные пользователи имели возможность делать запросы к API для получения важных данных. Аналогично, вы не хотите давать возможность посещать определенные HTML-страницы неавторизованным пользователям.
Если вы хотите обрабатывать запросы из приложения, которое не является браузером (например, из командной строки), вы не можете полагаться на браузерные "куки" для аутентификации. Вот почему большинство API использует собственные токены как часть процесса аутентификации. Мы поговорим чуть больше о токенах в следующем уроке.
Следующие шаги
Теперь у вас есть навыки использования вашего Rails-приложения для отдачи не только HTML, но и любого другого формата. Если вы хотите пойти дальше и позволить другим разработчикам создавать что-то с использованием вашей платформы (например, чтобы они могли делать программные запросы вместо аутентификации в качестве пользователя), вам понадобится сделать вашу API-систему намного более надежной. Мы не будем освещать все это здесь, но посмотрите следующие материалы:
Статья Building Awesome Rails APIs содержит описание множества лучших подходов для движения от игрушечного приложения в сторону стандартов промышленных API.
Сервис-ориентированная архитектура
Пришло время представить архитектурный подход под именем "Сервис-ориентированная архитектура" (Service-Oriented Architecture, SOA). Основная идея заключается в том, что ваше приложение будет состоять из множества сервисов, вроде системы оплаты, регистрации пользователей, модуля рекомендаций и т.д. Вместо того, чтобы создавать все это внутри одного главного приложения, вы разбиваете подсистемы на полностью независимые кусочки, которые взаимодействуют друг с другом, используя внутренние API-интерфейсы.
Это хорошо по многим причинам. Благодаря тому, что каждый кусочек вашего приложения не заботится о том, как работают другие части, и знает только как запросить данные через их API, вы можете делать значительные изменения в коде сервиса, и все остальное приложение будет работать, как и прежде. Вы можете полностью заменить один сервис на другой, и, пока он взаимодействует, используя те же API-методы, это пройдет очень гладко. Вы можете использовать внешние API как часть вашего приложения (например, платежные системы) вместо написания собственного. Вы можете создать PHP-приложение, взаимодействующее с Python-приложением, взаимодействующим с Rails-приложением, и все будет работать, ведь они общаются между собой с помощью API.
Как правило, стараться делать максимально независимой каждую часть вашего приложения - хорошая идея. Концепция СОА подталкивает вас мыслить в рамках того, какие именно методы вы хотите предоставлять другим частям вашего приложения, и заодно это сделает ваш код лучше. Вдобавок, предполагая, что каждый крупный компонент вашего приложения независим, вы также сможете намного легче выделять проблемы и обрабатывать ошибки более осмысленно.
Использовать сервис-ориентированную архитектуру для целого приложения - это что-то вроде разбиения гигантского сложного Ruby-скрипта на изящные классы и методы, только в большем масштабе.
Одним из наиболее известных случаев перехода на сервис-ориентированную архитектуру является Amazon.com. Однажды в 2002 году, Джефф Безос прямо заявил, что все рабочие группы должны перейти на СОА, или будут уволены. Печально известный пост из блога сотрудника Google, предназначенный внутрикорпоративных целей, но случайно ставший открытым для публики, рассказывал о мощи Amazon с использованием СОА. Это отличное чтиво, так что обязательно его оцените, но основные тезисы письма Безоса вынесены в следующие цитаты из поста:

1) Все команды отныне предоставляют свои данные и функциональность через интерфейсы сервисов.
2) Команды должны взаимодействовать друг с другом посредством этих интерфейсов.
3) Иные формы межпроцессного взаимодействия запрещены: никаких прямых ссылок, никакого непосредственного чтения данных другой команды, никаких моделей общей памяти, никаких "бэкдоров" и тому подобного. Единственный разрешенный способ взаимодействия - обращение к интерфейсу сервисов через сеть.
4) Неважно какую технологию они используют. HTTP, Corba, Pubsub, собственные протоколы - без разницы. Безоса это не волнует.
5) Все интерфейсы сервисов, без исключения, должны быть изначально спроектированы с возможностью управления извне. То есть, команда должна планировать и проектировать так, чтобы быть в состоянии предоставить интерфейс разработчикам вне компании. Никаких исключений.
6) Любой проигнорировавший эти требования будет уволен.

СОА - это серьезное дело. Несомненно, есть много проблем, которые всплывают при ее использовании - посмотрите этот пост о "извлеченных уроках" Amazon - но она имеет невероятно много преимуществ.
Вы, наверняка, не будете сильно беспокоиться о СОА, пока создаете "игрушечные" приложения для самих себя, но этот вопрос определенно встанет перед вами, когда вы начнете работать на ИТ компанию, поэтому знакомство с ней - это хорошая практика.
Ваша цель
Прочитайте раздел 7 руководства Rails по контроллерам , чтобы изучить рендеринг JSON и XML.
Они не обязательны к просмотру (потому что они идут немного дальше, чем мы сейчас подготовлены), но, если вам интересно, взгляните на Railscasts в разделе Дополнительных ресурсов внизу урока, чтобы больше узнать о преимуществах API.
Заключение
Мы плотнее поработаем с вашим приложением как с API во время курса по Javascript. В этом курсе вы создадите несколько полноценных (фулл-стэк) приложений, использующих AJAX-вызовы для лучшего пользовательского интерфейса, что по факту включает в себя рендеринг XML или JSON данных взамен полноценной HTML-страницы. Затем вы создадите несколько одностраничных Javascript-приложений, которые полагаются на API, предоставляемом вашим Rails-приложением, для получения всех необходимых данных из БД, а во всем остальном работающих на стороне клиента (в браузере).
Лучший способ разобраться с API - создать и взаимодействовать с ним, на чем мы сфокусируемся в наших проектах.