Шаг 2 «Конечные точки и методы (Описание API)»
Конечные точки указывают, как получить доступ к ресурсу, а метод указывает разрешенные взаимодействия (такие как GET, POST или DELETE) с ресурсом.
Один и тот же ресурс обычно имеет множество связанных конечных точек, каждая из которых имеет разные пути и методы, но возвращает различную информацию об одном и том же ресурсе. Конечные точки обычно имеют краткие описания, похожие на общее описание ресурса, только еще короче. Кроме того, конечная точка показывает только конечный путь URL ресурса, а не базовый, общий для всех конечных точек, путь.
Примеры конечных точек
Вот пример конечной точки ресурса User API Instagram
Конечная точка обычно выделяется стилизованным образом для придания ей более визуального внимания. Большая часть документации строится вокруг конечной точки, поэтому, может, имеет смысл визуально выделить конечную точку в нашей документации.
Конечная точка, возможно, является наиболее важным аспектом документации API, потому что она является тем, что разработчики будут реализовывать для выполнения своих запросов.
Представление параметра path при помощи фигурных скобок
Параметры path в конечных точках, представляют в фигурных скобках. Например, вот пример из API Mailchimp:
/campaigns//actions/send По возможности, параметр path выделяют другим цветом:
/campaigns//actions/send Фигурные скобки для параметров path являются условием, понятным пользователям. В приведенном выше примере почти ни одна конечная точка не использует фигурные скобки в синтаксисе фактического пути, поэтому является очевидным плэйсхолдером.
Вот пример из API Facebook, где параметр path выделен цветом для его легкой идентификации:
Для выделения параметров, при их описании в документации Facebook, используется зеленый цвет, который помогает пользователям понять их значение.
Параметры path не всегда выделяются уникальным цветом (например, некоторым может предшествовать двоеточие), но, как бы то ни было, нужно убедиться, что параметр path легко идентифицируется.
Перечисляем методы конечной точки
Для конечной точки обычно перечисляют методы (GET, POST и т. Д.). Метод определяет работу с ресурсом. Вкратце, каждый метод выглядит следующим образом:
- GET: получает ресурс;
- POST: создает ресурс;
- PUT: обновляет или создает в существующем ресурсе;
- PATCH: частично изменяет существующий ресурс;
- DELETE: Удаляет ресурс.
См. Request methods в статье Wikipedia по HTTP для получения дополнительной информации. (Существуют дополнительные методы, но они редко используются.)
Поскольку о самом методе особо говорить нечего, имеет смысл сгруппировать метод с конечной точкой. Вот пример из Box API:
А вот пример API LinkedIn:
Tip: Иногда этот метод называют глаголом. GET, PUT, POST, PATCH и DELETE — это все глаголы.
Конечная точка показывает только конечный путь
Когда мы описываем конечную точку, мы указываем только конечный путь (отсюда и термин «конечная точка»). Полный путь, который содержит как базовый путь, так и конечную точку, часто называют URL-адресом ресурса.
Как сгруппировать несколько конечных точек одного ресурса
Еще стоит обращать внимание при документировании конечных точек и методов, как группировать и перечислять конечные точки, особенно если у нас много конечных точек для одного и того же ресурса. В Примерах описания ресурсов мы рассмотрели различные API. Многие сайты документации используют различные схемы группировки или перечисления каждой конечной точки ресурса, поэтому не будем возвращаться к тем же примерам. Группируйте конечные точки таким образом, осмысленно, например, по методу или по типу возвращаемой информации.
Предположим, у нас есть три конечных точки GET и одна конечная точка POST, причем все они относятся к одному и тому же ресурсу. На некоторых сайтах документации все конечные точки для одного и того же ресурса могут перечисляться на одной странице. На других сайтах может встречаться разбивка методов на отдельных страницах. На третьих могут быть созданы одна группа для конечных точек GET, а другая — для конечных точек POST. Это зависит от того, что и сколько должно быть сказано о каждой конечной точке.
Если конечные точки в основном совпадают, объединение их на одной странице может иметь смысл. Но если они в значительной степени уникальны (с разными ответами, параметрами и сообщениями об ошибках), разделение их на разные страницы, вероятно, лучше (и проще в управлении). Опять же, создав более сложный дизайн сайта, мы можем сделать большую информацию доступной для навигации на той же странице.
Tip: В разделе, посвященном шаблонам проектирования, есть пояснение, что длинные страницы — это общий шаблон документации для разработчиков, отчасти потому, что они позволяют легко находить контент для разработчиков с помощью Ctrl + F .
Как ссылаться к конечным точкам в инструкциях
Как ссылаться к конечным точкам в разделе API в руководствах и другом безадресном контенте? Ссылка на конечную точку /aqi или на конечную точку /weatherdata не имеет большого значения. Но для более сложных API-интерфейсов использование конечной точки для описания ресурса может оказаться непростым делом.
В одной компании URL-адреса конечных точек ресурса Rewards выглядели так:
/rewards /rewards/ /users//rewards /users//rewards/
А Rewards в контексте Missions выглядели вот так:
/users//rewards/ /missions//rewards Сказать, что можно использовать ресурс Rewards, не всегда было достаточно конкретно, потому что было несколько Rewards и конечных точек Missions.
В этом случае, возможно, неудобно обращаться к конечной точке. Например, может быть такое предложение: «При вызове /users//rewards/ , вы получаете список всех наград. Чтобы получить конкретное вознаграждение за определенную миссию для конкретного пользователя, конечная точка /users//rewards/ принимает несколько параметров… »
Чем длиннее конечная точка, тем более громоздкой становится ссылка. Эти виды описаний будут чаще встречаться в концептуальных разделах вашей документации. Как правило, нет четкого правила, как ссылаться на громоздкие конечные точки. Смысловой подход нашего API определим самостоятельно.
Конечная точка API surfReport
Давайте создадим описание «Конечные точки и методы» для нашего вымышленного API Surfrefport. Вот пример:
Endpoints GET surfreport/ Получает условия серфинга для определенного идентификатора пляжа. Следующие шаги
Теперь, когда мы описали ресурс и перечислили конечные точки и методы, пришло время заняться одной из самых важных частей API: раздел “Параметры”.
Endpoint
Конечная точка или эндпоинт — это физическое устройство, которое подключаются к компьютерной сети и обменивается с ней информацией.
Примеры конечных точек: мобильные устройства (смартфоны и планшеты), ПК, ВМ, интегрированные устройства, серверы, IoT-устройства, например, камеры, системы безопасности, умные колонки, системы «умного дома».
Безопасность конечных точек
Эндпоинты располагаются вне зоны сетевой безопасности, конечные точки зависимы от пользователей. Фактически, они сами ответственны за безопасность, что повышает риски. Конечные точки — популярная цель для киберпреступников для кражи корпоративных данных.
Один из факторов, влияющих на уязвимость — все большее количество удаленных сотрудников в компаниях, которые работают на корпоративных устройствах из разных точек мира.
Главное средство безопасности эндпоинтов — классические антивирусы, защищающие IT-инфраструктуру от киберпреступников.
Также существуют другие действенные методы безопасности корпоративной среды:
- отслеживание подключаемых к сети устройств,
- Zero Trust — модель безопасности с постоянными проверками устройств, id и сервисов,
- шифрование,
- безопасные надежные пароли,
- постоянные обновления ОС, приложений и ПО.
Что такое эндпоинт в программировании?
Это конечная точка маршрута/цепи взаимодействия клиента с сервером, которой «скармливается» информация (или, с которой информация «берется»). Под сервером подразумевается программная сущность, а не аппаратное устройство.
Чаще всего, под эндпоинтом понимается сетевой адрес с путем и запросом, или ресурс по этому адресу. хотя это не всегда корректно, т. к. на одном адресе может находиться несколько эндпоинтов, и эндпоинты вполне могут быть нересурсными.
То есть, эндпоинтом может называться любое понятное указание на точку подключения (еще раз: эндпоинт это не адрес точки, а она сама).
Остальные ответы
конечная точка. типа конец
Что такое эндпоинт простыми словами?
Встречаются немного различные интерпретации этого понятия. Например такая. Каждый api-сервис имеет endpoint, к которому и нужно обращаться, например отправлять http-запрос. Обычно это url. Т.о. endpoint — это url. Или такая. url включает в себя маршрут (основная часть адреса сервиса) и endpoint (часть url, которая содержит например имя вызываемого метода). Существует один маршрут и у него несколько эндпоинтов. Т.о. здесь endpoint — это только часть url.
Ответ написан более двух лет назад
Комментировать
Нравится 4 Комментировать
Saboteur @saboteur_kiev Куратор тега Информационная безопасность
software engineer
Если говорить про веб, а чаще всего этот термин юзается в веб, то
На mysite.com может висеть ваше приложение
И у него могут быть ендпоинты
mysite.com/healthcheck
mysite.com/action.php
Ответ написан более двух лет назад
Комментировать
Нравится 3 Комментировать
System Integrator
Endpoint — это конечное защищаемое устройство. Компьютер с корпоративным антивирусом или мобилка с ним же. Хотя тут зависит от контекста, который вы не прояснили.
Ответ написан более двух лет назад
Комментировать
Нравится 2 Комментировать
Если бы мы пытались находить понятия в родном языке, а не заимствовали без перевода и понимания иностранные, то IT было бы менее загадочной областью. Замените слово «endpoint» в тексте на «адресат» (означает лицо или организацию, которым адресовано почтовое отправление) и всё встанет на свои места.
В контексте безопасности можно использовать «абонент».
«Адресат» и «абонент» близкие по смыслу слова.
Ответ написан 16 авг. 2023
Комментировать
Нравится 1 Комментировать
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- Linux
- +1 ещё
Что это такое и как защититься?
- 1 подписчик
- 6 часов назад
- 75 просмотров