Внедрение вашего API в производство
28 октября 2022 г.Когда вы выполняете поиск в Интернете по запросу «как создать API», я обнаружил довольно много вариантов, но очень немногие из них являются исчерпывающими руководствами. Это может быть связано с моими плохими способностями к поиску в Интернете или с тем, что довольно сложно создать API (от проектирования до производства).
Любой, кто работает с API, скажет вам, что это может быть настоящим подвигом, и обычно этим занимается команда людей. Поэтому самостоятельное создание API и запуск его в эксплуатацию, чтобы ваши пользователи могли начать его использовать, может оказаться серьезной проблемой.
Мы живем в удачное время, когда есть много инструментов, которые значительно облегчают эту задачу. С помощью чего-то вроде Postman мы можем создать спецификацию API, протестировать спецификацию API и, в конечном итоге, протестировать наш API, чтобы убедиться, что он работает должным образом. Чтобы создать серверную часть нашего API, нам понадобится множество инструментов, таких как Flask, Heroku и другие, или мы можем выбрать инструмент с низким кодом для создания и размещения нашего API.
В этом посте мы рассмотрим процесс создания API и способы повышения эффективности этого процесса.
Процесс разработки API
Разработка API сложна, ее невозможно обойти. Обычно нам нужно спроектировать API, закодировать, протестировать, отладить, снова закодировать, еще немного протестировать, развернуть, когда мы будем готовы, а затем, казалось бы, бесконечное обслуживание. Типичный жизненный цикл разработки API будет выглядеть примерно так:
Каждый шаг в этом процессе обычно выполняется с помощью другого инструмента или ресурса, поэтому внедрение API может стать довольно сложной задачей.
Например, мы можем использовать Postman для разработки нашего API (спецификация Open API) и использовать что-то вроде flask для нашей базы данных для подключения кода или какой-либо базы данных для хранения или извлечения наших данных. Нам также может понадобиться сделать дополнительные вызовы REST к другим API и службам. Для тестирования мы можем снова использовать Postman, но отладка кода и всех наших коннекторов может стать проблемой. Для развертывания мы можем выбрать Heroku, но это зависит от требований нашего API. Для мониторинга мы можем либо создать свою систему мониторинга, либо использовать что-то вроде Splunk. И когда нам нужно поддерживать наш API, нам нужно погрузиться во все это. Вы понимаете, что я пытаюсь сказать. Разработка API сложна.
Найти лучший способ
Мне нужен был способ упростить жизненный цикл разработки API и разработать свои API от проектирования до производства, используя всего несколько инструментов. Благодаря таким инструментам с низким кодом, как Linx, это возможно. Я смог создать API, от проектирования до развертывания, используя только три инструмента:
- Postman Я использовал postman для создания спецификации API (на основе YAML) и для тестирования моего API
- Linx Я использовал Linx для создания своего API, реализации логики, его отладки и, наконец, его размещения. Небольшое примечание: вы также можете попробовать свои силы в создании API с помощью этого пошагового руководства.
- SQL Server SQL Server использовался для хранения данных для моего API. Я использовал предварительно созданную базу данных AdventureWorks2019 и ее данные.
Требование
Я выбрал простой API, который будет вести пользовательские записи. API имеет пять методов:
Создание спецификации
Я создал простую спецификацию API в Postman, используя YAML, которая соответствует требованиям. Почтальон позволил мне увидеть, что я создал, и визуально предоставил дополнительную информацию. Создание определения API в Postman также приносит пользу, поскольку оно уже настраивает этот API для тестирования. При желании вы можете настроить сценарии тестирования на этом этапе.
Создание API
Теперь, когда у меня есть определение API, можно создать код. Linx позволяет импортировать спецификацию OpenAPI 3.0 и автоматически генерировать события для каждого указанного метода. Мне нужно было только указать URI, а затем построить логику.
Создание логики каждого события происходит относительно быстро после установки подключаемого модуля базы данных. Linx, как и любой другой инструмент, требует обучения, но как только вы поймете, как с ним работать, темп нарастает.
Я добавил логику и функциональность к каждому событию для API. Например, для метода GetAllUsers нам всем нужно было читать из базы данных SQL и возвращать результаты через тело ответа.
Тестирование API
Поскольку API уже настроен в Postman, было довольно легко протестировать в режиме реального времени, как работает API после того, как логика была реализована. На приведенном ниже GIF показано, как я использовал конструктор Linx для отладки созданного REST API и как я тестирую его в режиме отладки.
GIF 
Поскольку API отлаживается в Linx, он размещается на хостинге, поэтому я могу вызвать его, чтобы посмотреть, как он будет вести себя при развертывании. Это позволяет мне протестировать и получить фактический результат:
Конечно, мы также можем добавить сценарии тестирования в Postman, чтобы автоматизировать процесс тестирования. Эти сценарии гарантируют, что вы получите правильный ответ.
Развертывание API
Теперь, когда API спроектирован, разработан и протестирован, его необходимо развернуть. Это может быть серьезной задачей при традиционной разработке API, поскольку нам нужно придумать стратегию развертывания, выяснить, где мы будем что размещать, убедиться, что мониторинг и ведение журналов позаботятся, и многое другое.
Мое развертывание было довольно простым. Я развернул API из Linx Designer непосредственно на сервере Linx. Решение было построено, отправлено на сервер и готово к использованию примерно за 2 минуты. Сложность размещения API устранена, поскольку сервер Linx справляется с этим. Он также осуществляет мониторинг и регистрацию:
Я вызвал метод GetUser с неверным идентификатором, чтобы посмотреть, что произойдет, если произойдет непредвиденная ошибка. Сервер регистрирует ошибку и указывает красным цветом, что произошла ошибка:
Мне снова удалось вызвать API из Postman, и сервер каждый раз указывает, что API вызывается.
Конечно, я не добавлял в свой API никаких средств безопасности или аутентификации, но эти настройки доступны в дизайнере Linx. Другой вариант, который я пробовал, заключался в создании документации API в формате swagger. Это оказалось очень ценным, потому что при добавлении /swagger к базовому URI документация доступна и размещается вместе с самим API. Это упрощает распространение документации по API при необходимости.
Подведение итогов
При объединении Linx и Postman мы можем проектировать, создавать, документировать и размещать API. К нему нужно немного привыкнуть, как и к любому инструменту. Поскольку в Linx используются стандартные парадигмы программирования и жаргон, его легко понять, если вы знакомы с таким языком программирования, как C#. Я чувствую, что мы экономим больше всего времени при развертывании и размещении API с помощью Linx. Мониторинг и хостинг делаются за вас, а это значит, что о существенной головной боли позаботятся. Если регистрация и мониторинг недостаточно детализированы, вы можете добавить свои функции в решение Linx.
Если вы хотите попробовать создать API с помощью Linx, вы можете попробовать это сами
- используя сначала дизайн (с Postman) или
- сначала напишите код (просто соберите)
:::информация Также опубликовано здесь.
:::
Оригинал