Это вторая версия статьи на тему создания REST API с дополнительными комментариями по исходной статье для перевода.
49 995 просмотров
При работе с проектами по интеграции, для получения данных на сайт клиента, в CRM или мобильное приложение из базы данных под управлением MS SQL — реализуем стандартный REST API.
Проще всего создать такую интеграцию используя Node.js и два популярных npm-модуля Express (оснастка веб-сервера) и mssql (MS SQL Server клиент для Node.js).
Сначала создаем таблицы sales и invoices в базе данных SQL-сервера, процедуру для добавления записей в таблицу invoices и заполняем таблицу sales несколькими тестовыми записями:
Проверяем на SQL-сервере созданную таблицу и добавленные тестовые данные:
select * from sales
Переходим к созданию приложения в файле server.js добавляем код.
var express = require(‘express’); // оснастка веб сервера var app = express(); var sql = require(‘mssql’); // клиент для MS SQL Server // строка для подключения к базе данных. var sqlConfig = < user: ‘UserName’, password: ‘mot de passe’, server: ‘localhost’, database: ‘DatabaseName’ >// сервер для http://localhost:8081/ var server = app.listen(8081, function () < var host = server.address().address var port = server.address().port console.log(«сервер доступен по url http://%s:%s», host, port) >);
Урок 4. Python. Быстрый старт. Изучаем API сервиса
После сохранения файла server.js проверим работоспособность сервера и выполнения файла скрипта:
node server.js
сервер должен вернуть сообщение о доступности для выполнения запросов, например:
сервер доступен по url http://localhost:8081
Добавим в файл server.js код обработки запроса к web-серверу для получения всех данных из таблицы SQL сервера sales.
app.get(‘/sales’, function (req, res) < sql.connect(sqlConfig, function() < var request = new sql.Request(); request.query(‘select * from sales’, function(err, resp) < if(err) console.log(err); res.json(resp.recordset); // результат в формате JSON sql.close(); // закрываем соединение с базой данных >); >); >);
Сохраним файл, перезапустим сервер и проверим запрос в Postman, вернется JSON-объект с данными из таблицы SQL-сервера:
Усложняем запрос, добавим в обработчик параметр из URL для выборки по таблице invoices только запись с >
Передачу значения параметра из URL-запроса реализуем специальным отдельным методом — для исключения проблемы SQL-инъекций.
app.get(‘/sales/:id’, function (req, res) < sql.connect(sqlConfig, function() < var request = new sql.Request(); request.input(‘input_parameter’, sql.Int, Number(req.params.id)) // защита от SQL-инъекций и преобразование к числовому типу .query(‘select * from sales where function(err, resp) < if(err) console.log(err); res.json(resp.recordset); // результат в формате JSON sql.close(); // закрываем соединение с базой данных >); >); >);
Результат выполнения запроса, возврат отдельной записи из таблицы в формате JSON:
Парсинг криптобиржи | Торговый бот | API криптобиржи
В следующем обработчике запроса добавим в таблицу “invoices” запись с новым заказом, для REST это должен быть метод HTTP, тип запроса POST :
app.post(‘/sales/:id/invoices’, function (req, res) < sql.connect(sqlConfig, function() < var request = new sql.Request(); request.input(‘idSales’, sql.Int, Number(req.params.id)) // защита от SQL-инъекций .execute(‘addInvoices’, function(err, resp, returnValue, affected) < if(err) console.log(err); res.json(resp.recordset); // результат в формате JSON sql.close(); // закрываем соединение с базой данных >); >); >);
Для тестирования запросов типа POST требуется установка в браузер дополнения, использования отдельного приложения, например Postman, или же запрос возможно выполнить при помощи curl, используя командную строку:
В результате выполнения запроса получаем json с данными о добавленной записи в таблице invoices. При повторном выполнении новый ID и дата добавления записи.
В результате скрипт приложения server.js следующего содержания:
Дальнейшее дополнение скрипта приложения server.js это — включение в код обработчика ошибок, подключение к SQL через организацию пула соединений, обработка JSON встроенными функциями SQL-сервера.
Ссылка на источник для перевода и корректировки исходного кода статьи. Дополнительная информация по технологиям интеграции систем с использованием MS SQL-сервер — на сайте voInfo.ru.
16 комментариев
Написать комментарий.
Комментарий удален модератором
Развернуть ветку
Комментарий удален модератором
Развернуть ветку
Хранимка вам зачем?
Развернуть ветку
показан пример вызова процедуры, далее планировал рассмотреть варианты с передачей параметрами структуры json, использование out параметров, здесь возврат таблицы из процедуры
Развернуть ветку
MSSQL? Нода? «Проще всего»?
1. Большинство проектов от интернет-магазинов до персональных блогов использует MySQL, MongoDB, PostgreSQL, а не MSSQL.
2. REST само собой пишется на уже существующий стек, а не наоборот. И если проект написан на PHP, Java или GoLang — какой смысл тянуть ноду?
3. Компании, использующие не коробочные решения, работающие с MSSQL уже имеют специалистов, способных написать RESTful API с авторизацией, ограничениями и валидацией данных.
Развернуть ветку
Аккаунт удален
Развернуть ветку
Вот это я понимаю — образец объективных и обоснованных ответов.
Развернуть ветку
Автор, спасибо за проделанную работу!
Применимо в своём проекте ! Ещё раз благодарю
Развернуть ветку
Читаем и пишем без авторизации? =)
Развернуть ветку
актуальна авторизация на клиента в http запросе или на сессию подключения к sql серверу? При подключении к sql пул запросов под общей УЗ, в базе сессионные хэши на пользователей http.
Развернуть ветку
Да для клиента конечно. Или любой желающий сможет запросить информацию. А так, материал полезный. Немного ностальгии сразу свалилось, как раньше нужно было по быстрому апи накидать.
Еще как идея для статьи. Завернуть базу и сервис в докер-композ.
Развернуть ветку
Кстати, а нет информации, как эта БД нагрузку при большом количестве запросов держит? Скажем, при 100к запросов?
Развернуть ветку
использовал технологию In-Memory tables, достаточно эффективна при большой нагрузке
Развернуть ветку
Спасибо за статью, думая она пригодится многим начинающим программистам. Тем не менее, не однозначны пара моментов в данной статье.
Первое, указание данных для подключения напрямую в server.js. Для этих целей лучше использовать модуль dotenv и настройки хранить в отдельном файле, так как это упрощает развёртывание на дополнительных машинах, а также спасёт от компрометации данных о БД в репозитории в гитхабе.
Второе, кажется излишним повторять несколько раз похожие запросы к БД в коде. Более удобным представляется написать собственный модуль-обёртку поверх mssql. Данный модуль мог бы заниматься однотипными запросами с БД, и который можно многократно использовать в server.js. В server.js можно оставить только callback’ и с требуемой логикой.
С ростом объёма кода, это должно сильно упростить обслуживание кода. В принципе, вместе с пулом соединений, обозначенном в конце статьи, мне кажется это первое, с чего вообще стоило начинать. Чтобы делать правильно сразу 😉
Источник: vc.ru
Пишем свой API для сайта с использованием Apache, PHP и MySQL
Разрабатывая проект, я столкнулся с необходимостью организации клиент-серверного взаимодействия приложений на платформах iOS и Android с моим сайтом на котором хранилась вся информация — собственно БД на mysql, картинки, файлы и другой контент.
Задачи которые нужно было решать — достаточно простые:
регистрация/авторизация пользователя;
отправка/получение неких данных (например список товаров).
И тут-то мне захотелось написать свой API для взаимодействия с серверной стороной — большей своей частью для практического интереса.
Входные данные
В своем распоряжении я имел:
Сервер — Apache, PHP 5.0, MySQL 5.0
Клиент — Android, iOS устройства, любой браузер
Я решил, что для запросов к серверу и ответов от него буду использовать JSON формат данных — за его простоту и нативную поддержку в PHP и Android. Здесь меня огорчила iOS — у нее нет нативной поддержки JSON (тут пришлось использовать стороннюю разработку).
Так же было принято решение, что запросы можно будет отсылать как через GET так и через POST запросы (здесь помог $_REQUEST в PHP). Такое решение позволило проводить тестирование API через GET запросы в любом доступном браузере.
Внешний вид запросов решено было сделать таким:
http://[адрес сервера]/[путь к папке api]/?[название_api].[название_метода]=[JSON вида ]
Путь к папке api — каталог на который нужно делать запросы, в корне которого лежит файл index.php — он и отвечает за вызов функций и обработку ошибок
Название api — для удобства я решил разделить API группы — пользователь, база данных, конент и тд. В таком случае каждый api получил свое название
Название метода — имя метода который нужно вызвать в указанном api
JSON — строковое представление JSON объекта для параметров метода
Скелет API
Скелет API на серверной стороне состоит из нескольких базовых классов:
index.php — индексный файл каталога в Apache на него приходятся все вызовы API, он осуществляет парсинг параметров и вызов API методов
MySQLiWorker — класс-одиночка для работы с базой MySQL через MySQLi
apiBaseCalss.php — родительский класс для всех API в системе — каждый API должен быть наследован от этого класса для корректной работы
apiEngine.php — основной класс системы — осуществляет разбор переданных параметров (после их предварительного парсинга в index.php) подключение нужного класса api (через require_once метод), вызов в нем нужного метода и возврат результата в JSON формате
apiConstants.php — класс с константами для api вызовов и передачи ошибок
apitest.php — тестовый api для тестирования новых методов перед их включением в продакшн версию
Весь механизм выглядит следующим образом:
Мы делаем запрос на сервер — к примеру www.example.com/api будет принимать он.
0) < require_once ‘apiEngine.php’; foreach ($_REQUEST as $apiFunctionName =>$apiFunctionParams) < $APIEngine=new APIEngine($apiFunctionName,$apiFunctionParams); echo $APIEngine->callApiFunction(); break; > >else< $jsonError->error=’No function called’; echo json_encode($jsonError); > ?>
Первым делом устанавливаем тип контента — text/html (потом можно сменить в самих методах) и кодировку — UTF-8.
Дальше проверяем, что у нас что-то запрашивают. Если нет то выводим JSON c ошибкой.
Если есть параметры запроса, то подключаем файл движка API — apiEngine.php и создаем класс движка с переданными параметрами и делаем вызов api метода.
Выходим из цикла так как мы решили что будем обрабатывать только один вызов.
apiEngine.php
Вторым по важности является класс apiEngine — он представляет собой движок для вызова api и их методов.
//Конструктор //$apiFunctionName — название API и вызываемого метода в формате apitest_helloWorld //$apiFunctionParams — JSON параметры метода в строковом представлении function __construct($apiFunctionName, $apiFunctionParams) < $this->apiFunctionParams = stripcslashes($apiFunctionParams); //Парсим на массив из двух элементов [0] — название API, [1] — название метода в API $this->apiFunctionName = explode(‘_’, $apiFunctionName); > //Создаем JSON ответа function createDefaultJson() < $retObject = json_decode(‘<>’); $response = APIConstants::$RESPONSE; $retObject->$response = json_decode(‘<>’); return $retObject; > //Вызов функции по переданным параметрам в конструкторе function callApiFunction() < $resultFunctionCall = $this->createDefaultJson();//Создаем JSON ответа $apiName = strtolower($this->apiFunctionName[0]);//название API проиводим к нижнему регистру if (file_exists($apiName . ‘.php’)) < $apiClass = APIEngine::getApiEngineByName($apiName);//Получаем объект API $apiReflection = new ReflectionClass($apiName);//Через рефлексию получем информацию о классе объекта try < $functionName = $this->apiFunctionName[1];//Название метода для вызова $apiReflection->getMethod($functionName);//Провераем наличие метода $response = APIConstants::$RESPONSE; $jsonParams = json_decode($this->apiFunctionParams);//Декодируем параметры запроса в JSON объект if ($jsonParams) < if (isset($jsonParams->responseBinary))$functionName($jsonParams);//Вызываем метод в API >else< $resultFunctionCall->$response = $apiClass->$functionName($jsonParams);//Вызыаем метод в API который вернет JSON обект > > else < //Если ошибка декодирования JSON параметров запроса $resultFunctionCall->errno = APIConstants::$ERROR_ENGINE_PARAMS; $resultFunctionCall->error = ‘Error given params’; > > catch (Exception $ex) < //Непредвиденное исключение $resultFunctionCall->error = $ex->getMessage(); > > else < //Если запрашиваемый API не найден $resultFunctionCall->errno = APIConstants::$ERROR_ENGINE_PARAMS; $resultFunctionCall->error = ‘File not found’; $resultFunctionCall->REQUEST = $_REQUEST; > return json_encode($resultFunctionCall); > > ?>
apiConstants.php
Как написать программу api
Глава 6: Проектирование API
Брайан Кукси — опубликовано 22 апреля 2014
Эта глава знаменует собой поворотный момент в нашем приключении с API. Мы закончили изучение основ и теперь готовы посмотреть, как предыдущие концепции объединяются в API. В этой главе мы обсуждаем компоненты API, разрабатывая его.
Организация данных
По оценкам National Geographic, в 2011 году американцы сделали 80 миллиардов фотографий. Имея такое количество фотографий, вы можете представить себе разные подходы людей к их упорядочению на своих компьютерах. Некоторые предпочитают сбрасывать все в одну папку. Другие тщательно выстраивают свои фотографии в иерархию папок по годам, месяцам и событиям.
Подобным образом и компании относятся к структурированию при создании своих API. Как мы упоминали в главе 1, цель API — облегчить компьютерам работу с данными компании. Имея в виду простоту использования, одна компания может решить создать единый URL-адрес для всех данных и сделать его доступным для поиска (что-то вроде одной папки для всех ваших фотографий). Другая может решить дать каждому фрагменту данных свой собственный URL-адрес, организованный в виде иерархии (как с папками и подпапками для фотографий). Каждая компания выбирает лучший способ структурировать свой API для своей конкретной ситуации, руководствуясь существующими лучшими отраслевыми практиками.
Начните с архитектурного стиля
Обсуждая API, вы можете услышать разговоры о «мыле» (SOAP) и «отдыхе» (REST) и задаться вопросом, работают ли разработчики программного обеспечения или планируют отпуск. На самом деле это названия двух наиболее распространенных архитектур для веб-API. SOAP (изначально бывший сокращением, Simple Object Access Protocol) — это схема взаимодействия на основе XML, которая имеет стандартизованные структуры для запросов и ответов. REST, что означает «передача репрезентативного состояния» (Representational State Transfer), представляет собой более открытый подход, предусматривающий множество соглашений, но оставляющий многие решения на усмотрение человека, разрабатывающего API.
На протяжении этого курса вы, возможно, заметили, что у нас есть склонность к REST API. Это предпочтение во многом связано с невероятной скоростью принятия REST. Это не означает, что SOAP — зло; у него есть свои сильные стороны. Однако в центре нашего обсуждения останется REST, так как это, скорее всего, именно тот API, с которым вы столкнетесь. В остальных разделах мы рассмотрим компоненты, составляющие REST API.
Наш первый ресурс
Еще в главе 2 мы немного поговорили о ресурсах. Напомним, что ресурсы — это существительные в API-интерфейсах (клиенты и пицца). Это то, с чем мы хотим, чтобы мир мог взаимодействовать через наш API.
Чтобы понять, как компания разрабатывает API, давайте попробуем это сделать в нашей пиццерии. Начнем с добавления возможности заказать пиццу.
Чтобы клиент мог поговорить с нами о пицце, нам нужно сделать несколько вещей:
- Решить, какие ресурсы должны быть доступны.
- Назначить URL-адреса этим ресурсам.
- Решить, какие действия клиенту следует разрешить выполнять с этими ресурсами.
- Выяснить, какие фрагменты данных требуются для каждого действия и в каком формате они должны быть.
Следующим шагом будет присвоение URL-адресов ресурсу. Есть много возможностей, но, к счастью, соглашения REST дают некоторые рекомендации. В типичном REST API ресурсу будут назначены два шаблона URL. Первый — это множественное число от имени ресурса, например /orders . Второй — это множественное число от имени ресурса плюс уникальный идентификатор для указания одного ресурса, например /orders/ , где — уникальный идентификатор для заказа. Эти два шаблона URL составляют первые конечные точки (endpoints), которые будет поддерживать наш API. Они называются конечными точками просто потому, что они идут в конце URL-адреса, как в http://example.com/ .
Теперь, когда мы выбрали ресурс и присвоили ему URL-адреса, нам нужно решить, какие действия может выполнять клиент. Следуя соглашениям REST, мы говорим, что конечная точка множественного числа (/orders) предназначена для перечисления существующих заказов и создания новых. Множественное число с уникальным идентификатором конечной точки (/orders/ ) предназначено для извлечения, обновления или отмены определенного заказа. Клиент сообщает серверу, какое действие следует выполнить, передавая в запросе соответствующую команду HTTP (GET, POST, PUT или DELETE).
В целом наш API теперь выглядит так:
HTTP-запрос;Конечная точка;Действие;
GET;/orders;Перечислить существующие заказов POST;/orders;Разместить новый заказ GET;/orders/1;Получить подробности по заказу №1 GET;/orders/2;Получить подробности по заказу №2 PUT;/orders/1;Обновить заказ №1 DELETE;/orders/1;Отменить заказ №1
После того как действия для конечных точек нашего заказа продуманы, последний шаг — решить, какими данными необходимо обмениваться между клиентом и сервером. Заимствуя пример с пиццерией из главы 3, мы можем сказать, что заказ требует корочки и начинки. Нам также необходимо выбрать формат данных, который клиент и сервер могут использовать для передачи этой информации туда и обратно. И XML и JSON — хорошие кандидаты, но для удобства чтения мы выберем JSON.
На этом этапе вы можем себя поздравить; мы разработали работающий API! Вот как может выглядеть взаимодействие между клиентом и сервером с использованием этого API:
Рисунок 1. Пример взаимодействия между клиентом и сервером с использованием нашего API
Связывание ресурсов вместе
API нашей пиццерии выглядит отлично. Заказы поступают как никогда раньше. Бизнес идет настолько хорошо, что мы решили начать отслеживать клиентов заказов, чтобы оценивать их лояльность. Самый простой способ сделать это — добавить новый ресурс — клиента.
Как и в случае с заказами, нашему ресурсу Клиент нужны конечные точки. Следуя соглашению, /customers и /customers/ хорошо подходят. Опустим детали, но скажем, что нужно решить, какие действия имеют смысл для каждой конечной точки и какие данные представляют клиента. Предполагая, что мы все это сделаем, мы приходим к интересному вопросу: как связать заказы с покупателями?
Практики REST разделились во мнениях о том, как решить проблему связывания ресурсов. Некоторые говорят, что иерархия должна продолжать расти, давая конечные точки типа /customers/5/orders для всех заказов клиента №5. И /customers/5/orders/3 для третьего заказа клиента №5. Другие утверждают, что для упрощения ситуации необходимо включать связанные детали в данные для ресурса.
Согласно этой парадигме, создание заказа требует отправки поля customer_id с деталями заказа. Оба решения широко используются в REST API, поэтому стоит знать о каждом.
Рисунок 2. Два способа обработки связанных данных при разработке API
Поиск данных
По мере роста объема данных в системе, конечные точки, которые выдают полный перечень записей, становятся непрактичными. Представьте себе, что в нашей пиццерии было три миллиона выполненных заказов, и вы хотели бы узнать, в скольких из них есть пепперони в качестве начинки. Отправка запроса GET на /orders и получение всех трех миллионов заказов не очень помогает. К счастью, в REST есть отличный способ поиска данных.
У URL есть еще один компонент, о котором мы еще не упомянули — строка запроса (query string). Запрос означает поиск, а строка означает текст. Строка запроса — это фрагмент текста, который идет в конец URL-адреса для передачи данных в API. Например, все, что находится после вопросительного знака, является строкой запроса в http://example.com/orders?key=value.
API REST используют строку запроса для указания деталей поиска. Эти сведения называются параметрами запроса. API определяет, какие параметры он будет принимать, и их точные имена должны использоваться, чтобы они могли влиять на поиск. Наш API пиццерии может позволить клиенту искать заказы по топпингам их по следующему URL-адресу: http://example.com/orders?topping=pepperoni . Клиент может включать несколько параметров запроса, перечисляя один за другим, разделяя их амперсандом («). Например: http://example.com/orders?topping=pepperonisize=200, мы знаем, что ему нужна вторая страница результатов с 200 результатами на страницу, а именно заказы 201-400.
Источник: systems.education