Когда я занимался системным администрированием и операциями, я часто слышал термин API (интерфейс прикладного программирования). Я мало что знал о них, кроме того, что они были средством взаимодействия с данными в различных приложениях и базах данных. Пытаясь понять, как они работают, путем несложных исследований и бесед с коллегами, я пришел к элементарному пониманию того, что API бывает одной из двух версий: открытой или закрытой. Мое чрезмерно упрощенное определение «открытых API» (не путать с «OpenAPI») заключалось в том, что они позволяли пользователю не только потреблять, но и взаимодействовать с данными, тщательно выбирая, какую информацию он хочет извлечь при каждом обращении к серверу.

С другой стороны, я определил «закрытые API» как простое выплевывание данных по расписанию, предоставляя клиенту возможность самостоятельно изучить эти выходные данные, а затем доставить их в свои системы. Их единственная надежда определить, что на самом деле происходит с данными, заключалась в том, чтобы искать изменения от одного дампа данных к другому.

Эти определения удовлетворили мои потребности в понимании API для различных рабочих ролей. Мое относительное невежество было относительным блаженством.

С тех пор, как я начал свой буткемп шесть недель назад, я обнаружил, что ситуация, конечно же, более тонкая. Когда я углубился в CRUD и узнал о маршрутизации RESTful, стало ясно, что мое определение «открытого API» имеет множество различных применений и действий, некоторые из которых даже включают изменение данных на самом сервере. Этими возможностями можно управлять на стороне сервера, что позволяет провайдеру ограничивать поток (и потенциальное манипулирование) данными.

Все это я узнал из учебного текста моего курса и в лабораторных работах, но все это достигло апогея, когда я начал работать над трекером Международной космической станции (МКС) для моего группового проекта Фазы 2. Моя группа решила создать веб-сайт, посвященный информации о космических путешествиях, и одна из самых гениальных идей, которые у нас были, состояла в том, чтобы создать страницу, которая показывала бы координаты местоположения МКС на орбите на карте Земли. Мы знали, что есть способ просто сделать это, встроив существующий трекер ISS на страницу — таких трекеров много. Вот один от Европейского космического агентства:

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

Первое, что мне было нужно, это сами данные о местоположении. Координаты ISS легко доступны из нескольких API. Мы выбрали https://api.wheretheiss.at/v1/satellites/25544, так как он имеет простой однослойный вывод, включающий широту и долготу на верхнем уровне.

Итак, вперед к гонкам! Следующее, что нужно было сделать, это получить эти данные. Я добавил несколько перехватчиков ошибок, чтобы создать «лучший» опыт для пользователя, если он столкнулся с проблемами при загрузке страницы. Но в остальном это довольно стандартный запрос FETCH.

Мой запрос FETCH анализирует данные в JSON, затем берет эти данные и присваивает их точкам данных, представляющим координаты широты и долготы. Имея их в руках, я должен был придумать, что с ними делать. Для визуализации этих данных на карте очевидным решением стало использование Google Maps.

Я знал, что у Google Maps есть собственный API, позволяющий относительно легко интегрировать карты в приложения. Вам просто нужно создать проект на платформе Google Cloud, а затем запросить ключ API. (Как это сделать, можно найти в надежной документации Google здесь.)

Как только я получил свой ключ API, я понял, что не хочу волей-неволей использовать его в своем коде, поэтому я присвоил его переменной в файле secret.js проекта, а затем отметил эту папку в нашем .gitignore файл:

Следующим шагом был импорт функций GoogleMap, Marker и LoadScript React в мой компонент:

А затем включить эти элементы в мой отчет:

Со всем этим (и некоторыми другими функциями, на которые вы видите ссылки в моем коде), у меня на странице появилась карта. Ура!

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

После некоторых исследований я обнаружил, что для исправления этого мне нужно было фактически импортировать и использовать LoadScriptNext вместо LoadScript из инструментов Google React API. Я соответствующим образом изменил свой оператор импорта и обновил свои элементы JSX, чтобы вместо этого использовать LoadScriptNext, и это решило проблему загрузки, независимо от того, сколько раз я щелкал:

Моя следующая проблема заключалась в том, что, хотя карта отображалась (и обновлялась) с центром в правильном месте, на карте не было маркера, идентифицирующего МКС:

После значительного количества гугления я обнаружил, что по многим причинам в последних выпусках React требовалось использовать «MarkerF» вместо «Marker». И поэтому я обязан:

И маркер появился!

Миссия выполнена! Что ж, почти выполнено. Потому что, помните, я хотел что-то, что выглядело бы гладко и полностью интегрировалось в наш проект, с пользовательским значком, представляющим МКС на карте. К счастью, это было так же просто, как добавить изображение .png значка ISS в общую папку нашего проекта, а затем сослаться на него в элементе.

И, о чудо, у нас есть маленький значок космической станции, представляющий МКС на карте:

На этом пути было еще несколько препятствий… Мне нужно было убедиться, что моя страница вызывает API определения местоположения ISS с достаточной частотой, чтобы я не сталкивался с [429 Error] из-за слишком большого количества вызовов. (Возможно, я столкнулся с этим в какой-то момент, что заставило меня подумать о переключении API). Я исправил это с помощью эффекта, чтобы ограничить интервал вызова каждые 20 секунд, что находится в пределах ограничения API один раз в секунду.

И я должен был убедиться, что функция ограничения была размещена в правильном месте снаружизапроса FETCH (и писать код, пока у меня не было постоянной загрузки страницы в браузер), чтобы убедиться, что я не сразу начал получать отказы FETCH.

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

А теперь к следующему!