Rest endpoints что это: Базовые понятия (знания) в REST API

Posted:

Янв 15, 2023

Comments:

Rest endpoints что это: Базовые понятия (знания) в REST API — REST API

Содержание

Базовые понятия (знания) в REST API — REST API

Каждое понятие ниже играет важную роль в понимании WordPress REST API. Давайте ознакомимся с понятиями и фразами, которые используются в этом руководстве, чтобы иметь представление о чем речь. Подробнее каждое понятие прямо или косвенно рассмотрено в других разделах этого руководства.

Оглавление:

JSON

Это простой и удобный формат данных, который выглядит как объект в JavaScript, отсюда и название (JavaScript Object Notation). Пример JSON формата:

{
	"string": "строка",
	"integer": 25,
	"boolean": true,
	"array": [ 1, 2, 3 ],
	"object": {
		"string": "строка"
	}
}

REST получает и отдает JSON. Это позволяет разработчикам создавать, читать и обновлять контент WordPress с клиентского JavaScript или из внешних приложений, написанных на любом языке программирования.

Пример JSON ответа в REST API: https://wp-kama.ru/api/oembed/1.0/embed?url=https%3A%2F%2Fwp-kama.ru%2Fhandbook%2Frest%2Fbasic

Подробнее о JSON читайте в Википедии.

HTTP Клиент (или просто Клиент)

Инструмент, который используется для взаимодействия с REST API. Этот инструмент позволяет создавать HTTP запросы и умеет обрабатывать полученные ответы.

Таким инструментом может быть:

Postman — программа или расширение для Chrome.
REST Easy — расширение для Firefox для тестирования запросов в браузере
httpie — тестирование запросов в командной строке.
WordPress HTTP API — клиент самого WordPress. Его, например, можно использовать для доступа к одному сайту WordPress с другого.

Маршруты и Эндпоинты

Маршрут (Route — роут) — это «имя», которое отсылает работу API к определенным эндпоинтам. Если упростить, то можно сказать, что маршрут — это URL к которому можно обратиться разными HTTP методами. Маршрут может иметь несколько эндпоинтов.
Эндпоинт (Endpoint — конечная точка) — это само обращение к маршруту отдельным HTTP методом. Эндпоинт выполняют конкретную задачу, принимают параметры и возвращают данные Клиенту.

Разберем URL

http://example.com/wp-json/wp/v2/posts/123:

Здесь wp/v2/posts/123 — это маршрут, а /wp-json — это базовый путь самого REST API.
Этот маршрут имеет 3 эндпоинта:
- GET — запускает метод get_item() и возвращает данные поста Клиенту.
- PUT|PATCH|POST — запускает метод update_item(), обновляет данные и возвращает их Клиенту.
- DELETE — запускает метод delete_item(), удаляет пост и возвращает только что удаленные данные Клиенту.

Запрос к корневому маршруту

Если сделать GET запрос к корневому маршруту http://example.com/wp-json/, мы получим JSON ответ, в котором видно какие доступны маршруты, и какие доступны эндпоинты для каждого из них. При этом маршрут тут это / (корень), а при GET запросе он становится эндпоинтом (конечной точкой).

Маршрут без ЧПУ

На сайтах без ЧПУ маршрут (с претворяющем слэшем) добавляется в URL как значение параметра rest_route. Например:

http://example.com/?rest_route=/ — корневой маршрут.
http://example.com/?rest_route=/wp/v2/posts/123 — получение поста 123.

Пространство имён

Пространство имён — это начальная часть маршрута (префикс маршрута). Например, у WP есть маршрут wp/v2/posts, где wp/v2 — это пространство имён.

Пространство имен нужно, чтобы сделать название маршрута уникальным и таким образом избежать конфликтов при создании множества маршрутов разными плагинами/темами.

Пространство имени должно состоять из двух частей: vendor/package, где vendor — это поставщик (например название плагина или темы), а package — это версия кода указанного поставщика.

Для примера возьмем префикс WP — wp/v2:

wp — это первая часть — определяет имя модуля. Например, для плагина, там нужно указывать название плагина.
v2 — это вторая часть — определяет версию модуля. Например у WordPress была первая версия v1, но с расширением REST API код кардинально изменился и так появилась v2. Также может быть и с плагином, например, он писался и все было хорошо, пока не появились новые задачи и новый функционал, который несовместим со старой версией. И вот разработчик решает не улучшать текущую версию, а делать новую. Но при этом нужна обратная совместимость, чтобы старая версия работала как и прежде. Для этого создается новое пространство имени с v2 и туда пишется новый функционал, а старый v1 работает как работал.

Еще одно преимущество использования пространства имён — это то, что Клиенты смогут обнаружить ваше произвольное API. Список пространств отображается по главному запросу на корневой URL REST API:

{
  "name": "WordPress Site",
  "description": "Just another WordPress site",
  "url": "http://example. com/",
  "namespaces": [
	"wp/v2",
	"vendor/v1",
	"myplugin/v1",
	"myplugin/v2",
  ]
}

При регистрации произвольных маршрутов настоятельно рекомендуется указывать пространство имени!

Если вам нужно интегрироваться в пространство имени WP, то для создаваемого маршрута, можно указать пространство wp/v2. Однако делать это нужно с пониманием дела!

Что если не указать пространство имени?

Допустим мы хотим иметь маршрут /books. Регистрируем его с помощью register_rest_route(), в результате получаем такой URL маршрута: http://example.com/wp-json/books. Маршрут будет работать, но это плохая практика, поскольку мы в конечном итоге загрязняем потенциальные маршруты API!

Например, что если и другой плагин сделает тоже самое, тогда мы получим конфликт и один из маршрутов перестанет работать! Да, есть четвертый логический параметр register_rest_route(), который позволяет указать нужно ли перезаписывать существующий маршрут с таким же называнием, но это лишь лечение симптомов, а не болезни. Пространства имён позволяет не допускать подобных болезней.

CRUD

Сокращение от Create, Read, Update, Delete. Это короткое название всех видов операций маршрута, которые он позволяет делать: читать, создавать, обновлять и удалять что-либо (ресурс).

Ресурс

Ресурсы — это сущности в WordPress — это Посты, Страницы, Комментарии, Юзеры, Элементы таксономий (термины) и т.д.

WP-API позволяет HTTP-клиентам выполнять CRUD операции с ресурсами (create, read, update, delete).

Пример того, как REST API взаимодействует с ресурсами:

GET /wp-json/wp/v2/posts — получим коллекцию ресурсов (постов).
GET /wp-json/wp/v2/posts/123 — получим отдельный ресурс (пост 123).
POST /wp-json/wp/v2/posts — создадим новый ресурс (пост).
DELETE /wp-json/wp/v2/posts/123 — удалим ресурс (пост 123).

Путь к ресурсу

Путь к ресурсу — это имя ресурса в маршруте. Путь к ресурсу должен указывать, с каким ресурсом связана конечная точка. Например возьмем маршруты: wp/v2/posts и wp/v2/posts/{id}, тут путь к ресурсу будет /posts. Чтобы избежать конфликтов, путь к ресурсу должен быть уникальным в пределах текущего пространства имени.

Допустим, у нас есть плагин для интернет магазина и у него есть два основных типа ресурсов: заказы (на продукты) и продукты. Эти ресурсы связаны между собой, но это не одно и то же, и поэтому каждый из них должен «жить» по отдельному пути. Так, наши маршруты могут выглядеть следующим образом: /my-shop/v1/orders и /my-shop/v1/products.

Запрос

Один из основных классов в структуре WordPress REST API это WP_REST_Request. Этот класс используется для получения информации из запроса.

Запрос может быть отправлен удаленно через HTTP или внутренне из PHP. Объекты WP_REST_Request создаются автоматически при каждом запросе HTTP к маршруту. Данные, указанные в запросе определяют, какой ответ будет получен.

Ответ

Ответ — это данные которые вернутся из API в ответ на запрос. Ответы от конечных точек управляются классом WP_REST_Response. Класс предоставляет разные способы взаимодействия с данными ответа.

Ответы могут возвращать разные данные, в том числе JSON объект ошибки:

{
	"code": "rest_missing_callback_param",
	"message": "Отсутствует параметр: reassign",
	"data": {
		"status": 400,
		"params": [
			"reassign"
		]
	}
}

В заголовках ответа также указывается его статус код (200, 401). В REST API статус код часто важен, на его основе можно понять что не так с запросом. Подробнее про статус коды смотрите в отдельном разделе.

HTTP Методы

HTTP метод указывается при запросе Клиентом и определяет тип действия, которое Клиент хочет выполнить над ресурсом.

Методы которые используются в WP API:

GET — используются для получения (чтения) ресурсов (например постов).
POST — для создания ресурсов.
POST/PUT/PATCH — для обновления ресурсов.
DELETE — для удаления ресурсов.
OPTIONS — для получения полного описания маршрута.

Не все клиенты поддерживают все эти методы или может быть на сервере установлен фаервол, который запрещает некоторые методы.

Поэтому в WP API есть возможность указать такой метод по-другому:

в параметре запроса _method.
или в заголовке запроса X-HTTP-Method-Override.

Например, если нужно удалить ресурс, но для Клиента невозможно указать метод DELETE, то запрос можно отправить методом GET или POST, а сам метод передать в URL так: /wp-json/my-shop/v1/products/1?_method=DELETE. _method параметр имеет больший приоритет над реальным методом запроса и в этом случае WP API будет обрабатывать запрос как если бы он был отправлен методом DELETE.

Схема

Схема в REST API — это полное описание маршрута, оно рассказывает нам о маршруте все:

Какие в маршруте используются методы (GET POST).
Какие у него есть эндпоинты (конечные точки),
Какие у эндпоинта могут быть параметры.
Какими методами можно обращаться к эндпоинту.
Какую схему имеет ресурс (пост, коммент), с которым работает маршрут. Схема ресурса показывает какие будут возвращены поля при ответе на запрос при том или ином контексте.

Под словом «схема» можно понимать разные Схемы. В общем смысле — это Схема маршрута — это общая схема всего маршрута, в которую входят две схемы:

Схемы эндпоинтов — это то какими методами можно обращаться к эндпоинту и то какие ему можно передать параметры. Таких схем у маршрута обычно несколько.
Схема ресурса — это поля (данные) из которых состоит ресурс. Например, пост состоит из: заголовка, контента, даты и т.д.

В WP API схема представлена в виде JSON объекта и получить его можно сделав OPTIONS запрос на маршрут. Схема предоставляет машиночитаемые данные, поэтому любой Клиент который умеет читать JSON может понять с какими данными ему предстоит работать.

Рассмотрим пример

Возьмем маршрут /wp/v2/categories и посмотрим его схему:

$ curl -X OPTIONS -i http://demo.wp-api.org/wp-json/wp/v2/categories

GitHub

{
    "namespace": "wp/v2",
    "methods": [
        "GET",
        "POST"
    ],
    "endpoints": [
        {
            "methods": [
                "GET"
            ],
            "args": {
                "context": {
                    "required": false,
                    "default": "view",
                    "enum": [
                        "view",
                        "embed",
                        "edit"
                    ],
                    "description": "Рамки в которых сделан запрос, определяют поля в ответе.",
                    "type": "string"
                },
                "page": {
                    "required": false,
                    "default": 1,
                    "description": "Текущая страница коллекции.",
                    "type": "integer"
                },
                "per_page": {
                    "required": false,
                    "default": 10,
                    "description": "Максимальное число объектов возвращаемое в выборке. ",
                    "type": "integer"
                },
                "search": {
                    "required": false,
                    "description": "Ограничить результаты до совпадающих со строкой.",
                    "type": "string"
                },
                "exclude": {
                    "required": false,
                    "default": [],
                    "description": "Убедиться что выборка исключает определенные ID.",
                    "type": "array",
                    "items": {
                        "type": "integer"
                    }
                },
                "include": {
                    "required": false,
                    "default": [],
                    "description": "Ограничить выборку до определенных ID.",
                    "type": "array",
                    "items": {
                        "type": "integer"
                    }
                },
                "order": {
                    "required": false,
                    "default": "asc",
                    "enum": [
                        "asc",
                        "desc"
                    ],
                    "description": "Упорядочить сортировку атрибута по возрастанию или убыванию. ",
                    "type": "string"
                },
                "orderby": {
                    "required": false,
                    "default": "name",
                    "enum": [
                        "id",
                        "include",
                        "name",
                        "slug",
                        "include_slugs",
                        "term_group",
                        "description",
                        "count"
                    ],
                    "description": "Сортировать коллекцию по атрибутам элемента.",
                    "type": "string"
                },
                "hide_empty": {
                    "required": false,
                    "default": false,
                    "description": "Скрывать ли элементы не назначенные ни одной записи.",
                    "type": "boolean"
                },
                "parent": {
                    "required": false,
                    "description": "Ограничить выборку элементами назначенными определенному родителю. ",
                    "type": "integer"
                },
                "post": {
                    "required": false,
                    "description": "Ограничить выборку элементами назначенными определенной записи.",
                    "type": "integer"
                },
                "slug": {
                    "required": false,
                    "description": "Ограничить выборку элементами с одним или более специальными ярлыками. ",
                    "type": "array",
                    "items": {
                        "type": "string"
                    }
                }
            }
        },
        {
            "methods": [
                "POST"
            ],
            "args": {
                "description": {
                    "required": false,
                    "description": "HTML описание элемента.",
                    "type": "string"
                },
                "name": {
                    "required": true,
                    "description": "HTML название элемента. ",
                    "type": "string"
                },
                "slug": {
                    "required": false,
                    "description": "Буквенно-цифровой идентификатор элемента уникальный для его типа.",
                    "type": "string"
                },
                "parent": {
                    "required": false,
                    "description": "ID элемента родителя.",
                    "type": "integer"
                },
                "meta": {
                    "required": false,
                    "description": "Мета поля.",
                    "type": "object"
                }
            }
        }
    ],
    "schema": {
        "$schema": "http://json-schema.org/draft-04/schema#",
        "title": "category",
        "type": "object",
        "properties": {
            "id": {
                "description": "Уникальный идентификатор элемента.",
                "type": "integer",
                "context": [
                    "view",
                    "embed",
                    "edit"
                ],
                "readonly": true
            },
            "count": {
                "description": "Число опубликованных записей элемента. ",
                "type": "integer",
                "context": [
                    "view",
                    "edit"
                ],
                "readonly": true
            },
            "description": {
                "description": "HTML описание элемента.",
                "type": "string",
                "context": [
                    "view",
                    "edit"
                ]
            },
            "link": {
                "description": "URL элемента.",
                "type": "string",
                "format": "uri",
                "context": [
                    "view",
                    "embed",
                    "edit"
                ],
                "readonly": true
            },
            "name": {
                "description": "HTML название элемента.",
                "type": "string",
                "context": [
                    "view",
                    "embed",
                    "edit"
                ],
                "required": true
            },
            "slug": {
                "description": "Буквенно-цифровой идентификатор элемента уникальный для его типа. ",
                "type": "string",
                "context": [
                    "view",
                    "embed",
                    "edit"
                ]
            },
            "taxonomy": {
                "description": "Тип атрибуции элемента.",
                "type": "string",
                "enum": [
                    "category",
                    "post_tag",
                    "nav_menu",
                    "link_category",
                    "post_format"
                ],
                "context": [
                    "view",
                    "embed",
                    "edit"
                ],
                "readonly": true
            },
            "parent": {
                "description": "ID элемента родителя.",
                "type": "integer",
                "context": [
                    "view",
                    "edit"
                ]
            },
            "meta": {
                "description": "Мета поля.",
                "type": "object",
                "context": [
                    "view",
                    "edit"
                ],
                "properties": []
            }
        }
    },
    "_links": {
        "self": "http://wptest. ru/wp-json/wp/v2/categories"
    }
}

Схемы эндпоинтов:

В ключе endpoints мы видим «Схемы эндпоинтов», т.е. какие у маршрута есть конечные точки. Их тут две: GET (получит рубрики) и POST (создаст рубрику). И тут же описаны все возможные параметры для этих конечных точек.

Вот код схемы одного эндпоинта из кода выше (этот эндпоинт создает рубрику):

"endpoints": [
	{
		"methods": [
			"POST"
		],
		"args": {
			"description": {
				"required": false,
				"description": "HTML описание элемента.",
				"type": "string"
			},
			"name": {
				"required": true,
				"description": "HTML название элемента.",
				"type": "string"
			},
			"slug": {
				"required": false,
				"description": "Буквенно-цифровой идентификатор элемента уникальный для его типа.",
				"type": "string"
			},
			"parent": {
				"required": false,
				"description": "ID элемента родителя.",
				"type": "integer"
			},
			"meta": {
				"required": false,
				"description": "Мета поля. ",
				"type": "object"
			}
		}
	}
]

Схема ресурса:

В ключе schema мы видим «Схему ресурса», т.е. все аргументы JSON объекта, которые вернет API в случае удачного CRUD запроса.

Так выглядит схема ресурса (рубрики) из кода выше:

"schema": {
	"$schema": "http://json-schema.org/draft-04/schema#",
	"title": "category",
	"type": "object",
	"properties": {
		"id": {
			"description": "Уникальный идентификатор элемента.",
			"type": "integer",
			"context": [
				"view",
				"embed",
				"edit"
			],
			"readonly": true
		},
		"count": {
			"description": "Число опубликованных записей элемента.",
			"type": "integer",
			"context": [
				"view",
				"edit"
			],
			"readonly": true
		},
		"description": {
			"description": "HTML описание элемента.",
			"type": "string",
			"context": [
				"view",
				"edit"
			]
		},
		"link": {
			"description": "URL элемента.",
			"type": "string",
			"format": "uri",
			"context": [
				"view",
				"embed",
				"edit"
			],
			"readonly": true
		},
		"name": {
			"description": "HTML название элемента. ",
			"type": "string",
			"context": [
				"view",
				"embed",
				"edit"
			],
			"required": true
		},
		"slug": {
			"description": "Буквенно-цифровой идентификатор элемента уникальный для его типа.",
			"type": "string",
			"context": [
				"view",
				"embed",
				"edit"
			]
		},
		"taxonomy": {
			"description": "Тип атрибуции элемента.",
			"type": "string",
			"enum": [
				"category",
				"post_tag",
				"nav_menu",
				"link_category",
				"post_format"
			],
			"context": [
				"view",
				"embed",
				"edit"
			],
			"readonly": true
		},
		"parent": {
			"description": "ID элемента родителя.",
			"type": "integer",
			"context": [
				"view",
				"edit"
			]
		},
		"meta": {
			"description": "Мета поля.",
			"type": "object",
			"context": [
				"view",
				"edit"
			],
			"properties": []
		}
	}
}

Вот более читаемый вариант схемы ресурса (рубрики) из кода выше:

Параметр	Контекст	Описание
id число	`view, edit, embed`	ID термина (рубрики). Только для чтения.
count число	`view, edit`	Количество записей находящихся в термине (рубрике). Только для чтения.
description строка	`view, edit`	Описание термина (рубрики).
link строка, uri	`view, edit, embed`	URL термина (рубрики). Только для чтения.
name строка	`view, edit, embed`	Название термина (рубрики).
slug строка	`view, edit, embed`	Слаг (ярлык) термина (рубрики), обычно создается из названия.
taxonomy строка	`view, edit, embed`	Название таксономии. Только для чтения. Может быть: `category`, `post_tag`, `nav_menu`, `link_category`, `post_format`
parent число	`view, edit`	ID родительского термина.
meta объект	`view, edit`	Мета поля.

Контекст в схеме

Контекст — показывает какие поля объекта вернутся в ответе при создании запроса в указанном контексте. Например, при обновлении или создании рубрики вернутся поля соответствующие контексту edit.

Обнаружение

Это процесс выяснения любых деталей о работе с REST API. Например:

Клиент может попытаться «обнаружить» включен ли вообще REST API на сайте. См. Обнаружение REST API.
Клиент может прочитать Схему маршрута и понять, какие у него есть конечные точки и какая у него схема ресурса.

Контроллер

Это PHP класс созданный по разработанному разработчиками WP стандарту WP_REST_Controller.

Классы контроллеров объединяют отдельные части REST API в единый механизм. В них должны создаваться маршруты, они должны обрабатывать запросы, генерировать ответы API и описывать схему ресурса.

Концепция контроллера принята в рамках WP-API для того, чтобы иметь стандартный шаблон для классов контроллера — классов представляющих ресурсы (конечные точки). Шаблоном класса контроллера является абстрактный класс WP_REST_Controller. Каждый класс контроллера должен иметь аналогичную схему методов, сделано так для того, чтобы все конечные точки имели одинаковые названия PHP методов.

Подробнее читайте в разделе Классы контроллеров!

CURIE (компактный URL)

CURIEs — «Compact URIs» — URL записывается в компактном виде, чтобы понятно и универсально выглядеть в ответе API. Пример CURIE: https://api.w.org/term превратится в wp:term при генерации ответа API. Подробнее читайте в этом разделе.

Как создать эндпоинты и зачем они нужны? — Разработка на vc.ru

Эндпоинты — важная часть бизнес-процессов и в целом разработки приложений. В этой статье разбираем, что такое эндпоинты, для чего они нужны и как их создавать на платформе AppMaster. io.

15 272
просмотров

Что такое эндпоинт?

Эндпоинт (в переводе с англ. — конечная точка) представляет собой некий шлюз, который соединяет серверные процессы приложения с внешним интерфейсом. Простыми словами, это адрес, на который отправляются сообщения.

Чтобы понять, что такое эндпоинты, важно упомянуть работу API. API — аббревиатура от application programming interface, что переводится как программный интерфейс приложения. Приложения используют API для взаимодействия со сторонними приложениями и своими пользователями.

Чтобы связаться с API, нужно отправить ему запрос. Для корректной обработки запроса клиент должен предоставить универсальный указатель ресурса (URL), метод (HTTP method), и в зависимости от метода добавить заголовки (headers), тело (body), параметры запроса. Заголовки предоставляют метаданные о запросе, а тело содержит данные, например, поля для новой строки в базе данных.

API обработает запрос и отправит ответ, полученный от сервера. Ответ будет содержать код состояния, который является частью ответного сообщения HTTP, информирующего клиента о результате запроса. Например, код 200 используется, если операция завершилась успешно, 500 — если произошла внутренняя ошибка сервера.

Эндпоинты работают вместе с методами API. Это определенные URL-адреса, которые приложение использует для связи со сторонними службами и своими пользователями. URL — это роут, который может обрабатывать разные методы запроса. Каждый тип запроса — это отдельный эндпоинт. Существует пять основных типов:

GET — получает информацию с сервера, не требует тела запроса;
POST — создает в базе новый объект, требует тело запроса с полями этого объекта;
PUT — полностью обновляет конкретный объект в базе данных;
PATCH — аналогично PUT, обновляет определенный объект в базе данных, но обновляет только те поля, которые указаны в теле запроса;
DELETE — удаляет объект из базы данных.

При формировании конкретного запроса к нему могут добавляться разные параметры. Комбинация этих параметров и URL представляет URI — Uniform Resource Identifier (унифицированный идентификатор ресурса), который указывает, где и как найти ресурс.

Как настроить эндпоинты на платформе AppMaster.io?

В разделе Endpoints на платформе AppMaster.io вы можете увидеть все автоматически сгенерированные эндпоинты, а также эндпоинты вашего проекта. Если в вашем проекте включена автогенерация страниц и экранов, для любой созданной модели данных будут автоматически созданы соответствующие эндпоинты. Также эндпоинты могут быть созданы автоматически при установке некоторых модулей, например, Авторизация (Auth), Страны и города (Countries and Cities) и другие.

AppMaster.io позволяет работать с несколькими типами API эндпоинтов:

API для обращения к бэкенду от клиента и сторонних систем;
вебхуки для приема уведомлений от сторонних систем;
веб-сокеты, позволяющие открывать сеанс двусторонней интерактивной связи между браузером и сервером без необходимости запрашивать ответ у сервера.

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

При создании или редактировании эндпоинта в окне конфигурации вам доступны следующие опции:

Метод запроса: GET, POST, PUT, DELETE, или PATCH.
URL запроса. Первая часть с путем к серверу не указывается, так как она одинакова для всех эндпоинтов приложения. Достаточно указать окончание, например, /users. Тут же указывается и параметр URL. Допустим, эндпоинт предназначен для получения информации о конкретном пользователе, поэтому в качестве параметра передается его id записанный после “:” (/users/:id).
Endpoint Groups. Этот параметр служит исключительно для организации и структуризации работы с эндпоинтами. Все эндпоинты можно разделить по тематическим группам (папкам).
Business Process. Один из важнейших параметров, который определяет, что будет делать эндпоинт. При этом сам эндпоинт может оставаться неизменным, он будет получать все те же запросы по старому адресу, но в случае замены бизнес-процесса, выполнять другую функцию. Для основных действий с базой данных автоматически создаются бизнес-процессы, которые нельзя отредактировать, но при необходимости можно заменить на пользовательские БП.

Кроме того, вы можете настроить middleware (промежуточное программное обеспечение). Такого рода посредники служат для своеобразной фильтрации запросов приложения. Middleware используют для проверки каких-либо условий перед выполнением запроса. Например, если создать middleware для проверки аутентификации пользователя, тогда, если пользователь не залогинен, middleware перенаправит его на страницу логина. Если он уже же залогинен, middleware не будет вмешиваться в прохождение запроса, передавая его дальше клиенту.

Создание эндпоинта в AppMaster. io

Рассмотрим конфигурацию эндпоинтов на практике и разберем это на примере проекта Aviato. Весь процесс создания этого проекта вы можете найти на курсе AppMaster.io.

В рамках проекта мы создали два бизнес-процесса:

Validate and create flights — процесс, который будет использоваться для замены бизнес-процесса Create flight;
Register passenger — для регистрации пассажира на конкретный рейс.

Теперь мы можем использовать эти процессы для настройки эндпоинтов в проекте.

Начнем с бизнес-процесса Validate and create flights. В группе Flight уже есть эндпоинт POST/flights для создания рейса. Теперь нам нужно заменить привязанный к нему бизнес-процесс на новый. Для этого мы нажимаем на значок «Редактировать» (Edit).

В окне конфигурации необходимо выбрать нужный бизнес-процесс. В нашем случае это Validate and create flights. После этого нужно выбрать все входные переменные, которые нам понадобятся. Осталось только сохранить внесенные изменения.

Теперь можно настроить следующий эндпоинт для процесса Register passenger.

Наша цель — создать раздел для просмотра конкретного рейса и пассажиров, связанных с ним, а также настроить процесс регистрации новых пассажиров.

В группе эндпоинтов Flights нам нужно создать новый эндпоинт: /flights/:id/register, где id относится к конкретному рейсу, который мы можем использовать в качестве входных данных в бизнес-процессе.

Нажав на иконку Plus, мы можем добавить новый эндпоинт. Метод запроса будет POST, так как мы создаем новый объект. В строке бизнес-процесса выбираем процесс Register passenger. Осталось сохранить эти изменения.

Вот так довольно легко можно создавать эндпоинты на платформе AppMaster.io.

Заключение

Эндпоинты — неотъемлемая часть в работе API, который в свою очередь необходим для расширения проектов и удобной интеграции сервисов и приложений. No-code платформа AppMaster.io позволяет легко работать с эндпоинтами, создавать и настраивать их. Вы всегда можете зарегистрироваться на платформе и проверить весь функционал.

Понимание и использование REST API — Smashing Magazine

Чтение за 14 мин.
API,
РЕСТ API,
JavaScript
Поделиться в Twitter, LinkedIn

Об авторе

Zell — разработчик из Сингапура. Он преподает разработку интерфейса через свой блог. Он также написал курсы «Изучай JavaScript» и «Автоматизируй свой…
Больше о
Zell ↬

Если вы хотите иметь возможность читать документацию по API и эффективно ее использовать, вам сначала нужно понять все об API REST. Давайте начнем.

Скорее всего, вы столкнулись с термином «REST API», если думали о получении данных из другого источника в Интернете, такого как Twitter или Github. Но что такое REST API? Что это может сделать для вас? Как вы используете его?

В этой статье вы узнаете все, что вам нужно знать об API REST, чтобы иметь возможность читать документацию по API и эффективно их использовать.

Что такое REST API

Допустим, вы пытаетесь найти видео о Бэтмене на Youtube. Вы открываете Youtube, вводите «Бэтмен» в поле поиска, нажимаете «Ввод», и вы видите список видео о Бэтмене. REST API работает аналогичным образом. Вы что-то ищете и получаете список результатов от службы, которую вы запрашиваете.

API — это интерфейс прикладного программирования. Это набор правил, позволяющих программам взаимодействовать друг с другом. Разработчик создает API на сервере и позволяет клиенту общаться с ним.

REST определяет, как выглядит API. Это расшифровывается как «Репрезентативная государственная передача». Это набор правил, которым следуют разработчики при создании своего API. Одно из этих правил гласит, что вы должны иметь возможность получить часть данных (называемую ресурсом), когда вы ссылаетесь на определенный URL-адрес.

Каждый URL-адрес называется запросом , а данные, отправляемые вам обратно, называются ответом .

Анатомия запроса

Важно знать, что запрос состоит из четырех элементов:

Конечная точка
Метод
Заголовки

Данные (или тело)

4 Конечная точка (или маршрут) — это URL-адрес, который вы запрашиваете. Он имеет следующую структуру:

 root-endpoint/?

Корневая конечная точка — это начальная точка API, от которого вы запрашиваете. Корневая конечная точка API Github — https://api.github.com , а корневая конечная точка API Twitter — https://api.twitter.com .

Путь определяет ресурс, который вы запрашиваете. Думайте об этом как об автоответчике, который просит вас нажать 1 для услуги, нажать 2 для другой услуги, 3 для еще одной услуги и так далее.

Больше после прыжка! Продолжить чтение ниже ↓

Вы можете получить доступ к путям так же, как вы можете ссылаться на части веб-сайта. Например, чтобы получить список всех сообщений с тегом «JavaScript» в журнале Smashing Magazine, перейдите по адресу https://www.smashingmagazine.com/tag/javascript/. https://www.smashingmagazine.com/ — это корневая конечная точка, а /tag/javascript — это путь.

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

 /пользователи/:имя пользователя/репозитории

Любые двоеточия ( : ) в пути обозначают переменную. Вы должны заменить эти значения фактическими значениями при отправке запроса. В этом случае вам следует заменить :username на фактическое имя пользователя, которого вы ищете. Если я ищу свою учетную запись Github, я заменю :username на zellwk .

Конечная точка для получения списка моих репозиториев на Github:

 https://api.github.com/users/zellwk/repos

Последняя часть конечной точки — это параметры запроса . Технически параметры запроса не являются частью архитектуры REST, но вы увидите, что многие API используют их. Итак, чтобы помочь вам полностью понять, как читать и использовать API, мы также поговорим о них.
Параметры запроса дают вам возможность изменить ваш запрос с помощью пар ключ-значение. Они всегда начинаются со знака вопроса ( ? ). Затем каждая пара параметров отделяется амперсандом ( и ), например:

 ?запрос1=значение1&запрос2=значение2

Когда вы пытаетесь получить список репозиториев пользователя на Github, вы добавляете в свой запрос три возможных параметра, чтобы изменить предоставленные вам результаты:

Github позволяет вам добавить три параметра в ваш запрос

Если вы хотите получить список репозиториев, которые я недавно отправил, вы можете установить sort на push .

 https://api.github.com/users/zellwk/repos?sort=push

Как узнать, работает ли эта конечная точка? Что ж, пора попробовать!

Тестирование конечных точек с помощью curl

Вы можете отправить запрос на любом языке программирования. Пользователи JavaScript могут использовать такие методы, как Fetch API и метод jQuery Ajax; Пользователи Ruby могут использовать класс Ruby Net::HTTP, пользователи Python могут использовать запросы Python; и так далее.

В этой статье мы будем использовать утилиту командной строки под названием cURL. Мы используем cURL, потому что документация API обычно пишется со ссылкой на cURL. Если вы понимаете, как использовать cURL, у вас не возникнет проблем с пониманием документации по API. Затем вы можете легко выполнять запросы на предпочитаемом вами языке.

Прежде чем продолжить, убедитесь, что на вашем компьютере установлен cURL. Откройте терминал и введите curl-version . Эта команда проверяет версию cURL, установленную в вашей системе.

 завиток --версия

Если у вас не установлен cURL, вы получите сообщение об ошибке «команда не найдена». Если вы получили эту ошибку, вам нужно будет установить curl, прежде чем двигаться дальше.

Чтобы использовать cURL, введите curl , а затем конечную точку, которую вы запрашиваете. Например, чтобы получить корневую конечную точку Github, введите следующее:

 завиток https://api.github.com

После того, как вы нажмете Enter, вы должны получить ответ от Github, который выглядит следующим образом:

Ответ от корневой конечной точки Github

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

 curl https://api.github.com/users/zellwk/repos

Если вы хотите включить параметры запроса с помощью cURL, убедитесь, что вы добавили обратную косую черту ( \) до ? и = символов. Это потому что ? и = — специальные символы в командной строке. Вам нужно использовать \ перед ними, чтобы командная строка интерпретировала их как обычные символы:

 curl https://api.github.com/users/zellwk/repos\?sort\=push

Попробуйте использовать любую команду и выполните запрос! Вы получите аналогичный ответ тому, что вы видели с корневым конечным пунктом Github (но с гораздо большим количеством данных).

JSON

JSON (обозначение объектов JavaScript) — общий формат для отправки и запроса данных через REST API. Ответ, который Github отправляет вам, также имеет формат JSON.

Объект JSON выглядит как объект JavaScript. В JSON каждое свойство и значение должны быть заключены в двойные кавычки, например:

 {
  "свойство1": "значение1",
  "свойство2": "значение2",
  "свойство3": "значение3"
}

Назад к анатомии запроса

Вы узнали, что запрос состоит из четырех частей.

Конечная точка
Метод
Заголовки
Данные (или тело)

Давайте пройдемся по остальной части запроса.

Метод

Метод — это тип запроса, который вы отправляете на сервер. Вы можете выбрать один из следующих пяти типов:

GET
POST
PUT
PATCH 099060
04
040060

Эти методы придают смысл вашему запросу. Они используются для выполнения четырех возможных действий: Создать , Прочитать , Обновить и Удалить (CRUD).

Имя метода	Запрос Значение
`GET`	Этот запрос используется для получения ресурса с сервера. Если вы выполняете запрос GET, сервер ищет запрошенные вами данные и отправляет их вам. Другими словами, запрос GET выполняет операцию READ. Это метод запроса по умолчанию.
`POST`	Этот запрос используется для создания нового ресурса на сервере. Если вы выполняете запрос POST, сервер создает новую запись в базе данных и сообщает вам, успешно ли создано. Другими словами, запрос POST выполняет операцию CREATE.
`PUT` и `PATCH`	Эти два запроса используются для обновления ресурса на сервере. Если вы выполняете запрос PUT или PATCH, сервер обновляет запись в базе данных и сообщает вам, успешно ли выполнено обновление. Другими словами, запрос PUT или PATCH выполняет операцию UPDATE.
`DELETE`	Этот запрос используется для удаления ресурса с сервера. Если вы выполняете запрос `DELETE`, сервер удаляет запись в базе данных и сообщает вам, успешно ли удаление. Другими словами, запрос `DELETE` выполняет операцию `DELETE`.

API позволяет узнать, какой метод запроса использовать для каждого запроса. Например, чтобы получить список репозиториев пользователя, вам нужен запрос GET :

Требуется GET-запрос, чтобы получить список репозиториев от пользователя

Для получения списка репозиториев от пользователя требуется запрос GET. Чтобы создать новый репозиторий Github, вам нужен запрос POST :

Для создания нового репозитория требуется запрос POST

. Вы можете установить метод запроса в cURL, написав -X или --request , а затем метод запроса. Эта команда ниже пытается создать репозиторий через cURL:

 curl -X POST https://api. github.com/user/repos

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

 {
  "message": "Требуется аутентификация",
  "documentation_url": "https://developer.github.com/v3"
}

Заголовки

Заголовки используются для предоставления информации как клиенту, так и серверу. Его можно использовать для многих целей, таких как аутентификация и предоставление информации о содержимом тела. Вы можете найти список допустимых заголовков в Справочнике HTTP-заголовков MDN.

Заголовки HTTP представляют собой пары "свойство-значение" , разделенные двоеточием. В приведенном ниже примере показан заголовок, указывающий серверу ожидать содержимое JSON.

 "Тип контента: приложение/json". Пропало открытие».

Вы можете отправлять заголовки HTTP с помощью curl с помощью опции -H или --header . Чтобы отправить указанный выше заголовок в API Github, используйте следующую команду:

 curl -H "Content-Type: application/json" https://api. github.com

(Примечание: заголовок Content-Type не является требование для работы Github API. Это всего лишь пример, иллюстрирующий, как использовать заголовок с cURL).

Чтобы просмотреть отправленные вами заголовки, вы можете использовать -v или --verbose вариант при отправке запроса, например:

 curl -H "Тип содержимого: приложение/json" https://api.github.com -v

cURL сообщает вам дополнительную информацию, которая включает заголовки, когда вы используете подробный параметр

Здесь * относится к дополнительной информации, предоставленной cURL. > относится к заголовкам запросов, а < относится к заголовкам ответов.

Данные (или «тело»)

Данные (иногда называемые «телом» или «сообщением») содержат информацию, которую вы хотите отправить на сервер. Эта опция используется только с запросами POST , PUT , PATCH или DELETE .

Чтобы отправить данные через cURL, вы можете использовать параметр -d или --data :

 curl -X POST  -d property1=value1

Чтобы отправить несколько полей данных, вы можете создать несколько параметров -d :

 curl -X POST  -d свойство1=значение1 -d свойство2=значение2

Если есть смысл, можно разбить запрос на несколько строк \ для удобства чтения:

 curl -X POST  \
  -d свойство1=значение1 \
  -d свойство2=значение2

Если вы знаете, как раскрутить сервер, вы можете создать API и протестировать свои собственные данные. Если вы не знаете, но чувствуете себя достаточно смелым, чтобы попробовать, вы можете следовать этой статье, чтобы научиться создавать сервер с Node, Express и MongoDB

Если вы не хотите раскручивать свой сервер, вы можете перейти к Запросбин.com ( это бесплатно! ) и нажмите «создать конечную точку». Вам будет предоставлен URL-адрес, который вы можете использовать для проверки запросов, например https://requestb. in/1ix963n1 , как показано на рисунке ниже.

Корзина запросов дает вам уникальный URL-адрес, который вы можете использовать в течение 48 часов.

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

Теперь попробуйте отправить данные в корзину запросов, а затем обновите веб-страницу своей корзины. Вы увидите некоторые данные, например:

 curl -X POST https://requestb.in/1ix963n1 \
  -d свойство1=значение1 \
  -d свойство2=значение2

Запросы, отправленные вами в корзину, будут выглядеть следующим образом.

По умолчанию cURL отправляет данные, как если бы они отправлялись через «поля формы» на странице. Если вы хотите отправить данные JSON, вам нужно установить Content-Type на application/json , и вам нужно будет отформатировать ваши данные как объект JSON, например:

 curl -X POST https://requestb. in/1ix963n1 \
  -H "Тип контента: приложение/json" \
  -д '{
  "свойство1":"значение1",
  "свойство2":"значение2"
}'

Отправка данных в формате JSON

И это (почти!) все, что вам нужно знать о структуре запроса.

Помните, когда вы пытались отправить запрос POST через API Github, вы получили сообщение «Требуется аутентификация»? Ну, это потому, что вы не авторизованы для выполнения запроса POST !

`Аутентификация`

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

Поскольку запросы POST , PUT , PATCH и DELETE изменяют базу данных, разработчики почти всегда помещают их за стену аутентификации. В некоторых случаях запрос GET также требует аутентификации (например, когда вы получаете доступ к своему банковскому счету для проверки текущего баланса).

В Интернете существует два основных способа аутентификации:

С помощью имени пользователя и пароля (также называется базовой аутентификацией)
С секретным токеном

Метод секретного токена включает oAuth, который позволяет вам аутентифицировать себя в социальных сетях, таких как Github, Google, Twitter, Facebook и т. д.

В этой статье вы только научитесь использовать базовая аутентификация с использованием имени пользователя и пароля. Если вы заинтересованы в аутентификации с помощью oAuth, я предлагаю прочитать «Что вам нужно знать об OAuth3 и входе в систему через Facebook» Зака Гроссбарта.

Чтобы выполнить базовую аутентификацию с помощью cURL, вы можете использовать -u , затем ваше имя пользователя и пароль, например:

 curl -x POST -u "имя пользователя:пароль" https://api.github.com/user/repos

Попробуйте пройти аутентификацию с помощью имени пользователя и пароля в приведенном выше запросе. После успешной аутентификации вы увидите, что ответ изменится с «Требуется аутентификация» на «Проблемы при синтаксическом анализе JSON».

Это потому, что вы еще не предоставили какие-либо данные (которые требуются для всех POST , PUT , PATCH и DELETE запросы) на сервер.

Обладая полученными знаниями, вы сможете отредактировать приведенный выше код, чтобы создать репозиторий Github через ваш cURL. Я бы оставил вас, чтобы попробовать это сами!

Теперь поговорим о кодах состояния HTTP и сообщениях об ошибках.

Некоторые сообщения, которые вы получили ранее, такие как «Требуется аутентификация» и «Проблемы при синтаксическом анализе JSON», являются сообщениями об ошибках. Они появляются только тогда, когда что-то не так с вашим запросом. Коды состояния HTTP позволяют быстро сообщить статус ответа. Диапазон от 100+ до 500+. В общем, числа подчиняются следующим правилам:

200+ означает, что запрос выполнен успешно .
300+ означает, что запрос - , перенаправленный на другой URL
400+ означает ошибку , которая возникает из клиента , возникла
500+ произошло

Вы можете отлаживать статус ответа с помощью подробной опции ( -v или --verbose ) или вариант головки ( -I или --head ).

Например, если вы попытались добавить -I к запросу POST без указания имени пользователя и пароля, вы получите код состояния 401 (Неавторизованный):

Пример несанкционированного запроса

Если ваш запрос недействителен поскольку ваши данные неверны или отсутствуют, вы обычно получаете код состояния 400 (неверный запрос).

Пример неправильного запроса

Чтобы получить дополнительную информацию о конкретных кодах состояния HTTP, вы можете обратиться к Справочнику по состоянию HTTP MDN.

`Версии API`

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

Вы можете запросить конкретную версию API двумя способами. Какой способ вы выберете, зависит от того, как написан API.

Эти два способа:

Непосредственно в конечной точке
В заголовке запроса

Twitter, например, использует первый метод. На момент написания статьи API Twitter имел версию 1.1, о чем свидетельствует его конечная точка:

 https://api.twitter.com/1.1/account/settings.json.

Github, с другой стороны, использует второй метод. На момент написания Github API имеет версию 3, и вы можете указать версию с заголовком Accept :

 curl https://api.github.com -H Accept:application/vnd.github.v3+ json

`Подведение итогов`

В этой статье вы узнали, что такое REST API и как использовать cURL для выполнения запроса с помощью методов GET , POST , PUT , PATCH и 0 DELETE 9 . Кроме того, вы также узнали, как аутентифицировать свои запросы с помощью параметра -u и что означают статусы HTTP.

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

`REST и SOAP`

перейти к содержанию

Введите ключевые слова

Поддержка Приставка Начать пробную версию

Контакт

Выберите язык 简体中文EnglishFrançaisDeutschItaliano日本語한국어PortuguêsEspañol

Связаться с нами

`Выберите язык`

简体中文
Английский
Français
Deutsch
Итальян
日本語
한국어
0004
Испанский

Добро пожаловать,

Войдите в свою учетную запись Red Hat

Войдите в систему

Ваша учетная запись Red Hat дает вам доступ к вашему профилю участника и настройкам, а также к следующим услугам в зависимости от вашего статуса клиента:

Зарегистрируйтесь сейчас

Еще не зарегистрированы? Вот несколько причин, по которым вы должны это сделать:

Просматривайте статьи базы знаний, управляйте обращениями в службу поддержки и подписками, загружайте обновления и многое другое из одного места.
Просмотр пользователей в вашей организации и изменение информации об их учетных записях, предпочтениях и разрешениях.
Управляйте своими сертификатами Red Hat, просматривайте историю экзаменов и загружайте логотипы и документы, связанные с сертификацией.

Редактировать свой профиль и предпочтения

Ваша учетная запись Red Hat дает вам доступ к вашему профилю участника, предпочтениям и другим услугам в зависимости от вашего статуса клиента.

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

Выход из системы

Логин аккаунта

`Выберите язык`

简体中文
Английский
Français
Deutsch
Italiano
日本語
한국어
Português
Español

9

REST и SOAP — это два разных подхода к онлайновой передаче данных. В частности, оба определяют, как создавать интерфейсы прикладного программирования (API), которые позволяют передавать данные между веб-приложениями. Передача репрезентативного состояния (REST) — это набор архитектурных принципов. Простой протокол доступа к объектам (SOAP) — это официальный протокол, поддерживаемый консорциумом World Wide Web (W3C). Основное отличие состоит в том, что SOAP — это протокол, а REST — нет. Как правило, API придерживается либо REST, либо SOAP, в зависимости от варианта использования и предпочтений разработчика.
Загрузить руководство пользователя нашего API
REST — это набор архитектурных принципов, адаптированных к потребностям облегченных веб-служб и мобильных приложений. Поскольку это набор рекомендаций, реализация этих рекомендаций предоставляется разработчикам.
Когда запрос данных отправляется в REST API, это обычно выполняется через протокол передачи гипертекста (обычно называемый HTTP). После получения запроса API-интерфейсы, разработанные для REST (называемые RESTful API или веб-службами RESTful), могут возвращать сообщения в различных форматах: HTML, XML, обычный текст и JSON. JSON (объектная нотация JavaScript) предпочтительнее в качестве формата сообщения, потому что он может быть прочитан любым языком программирования (несмотря на название), удобен для чтения человеком и машиной и имеет небольшой вес. Таким образом, RESTful API более гибкие и их проще настроить.
Приложение называется RESTful, если оно соответствует 6 архитектурным рекомендациям. Приложение RESTful должно иметь:
1. Архитектуру клиент-сервер, состоящую из клиентов, серверов и ресурсов.
2. Взаимодействие клиент-сервер без сохранения состояния, означающее, что содержимое клиента не сохраняется на сервере между запросами. Вместо этого информация о состоянии сеанса хранится у клиента.
3. Кэшируемые данные для устранения необходимости в некоторых взаимодействиях клиент-сервер.
4. Единый интерфейс между компонентами, чтобы информация передавалась в стандартизированной форме, а не в соответствии с потребностями приложения. Это описывается Роем Филдингом, создателем REST, как «центральная особенность, которая отличает архитектурный стиль REST от других сетевых стилей».
5. Ограничение многоуровневой системы, при котором взаимодействие клиент-сервер может быть опосредовано иерархическими уровнями.
6. Код по запросу, позволяющий серверам расширять функциональные возможности клиента путем передачи исполняемого кода (хотя это также снижает видимость, что делает это необязательным правилом).
SOAP — это стандартный протокол, изначально разработанный для того, чтобы приложения, созданные на разных языках и на разных платформах, могли обмениваться данными. Поскольку это протокол, он налагает встроенные правила, которые увеличивают его сложность и накладные расходы, что может привести к увеличению времени загрузки страницы. Однако эти стандарты также предлагают встроенные соответствия, которые могут сделать их предпочтительными для корпоративных сценариев. Встроенные стандарты соответствия включают безопасность, атомарность, согласованность, изоляцию и надежность (ACID), которые представляют собой набор свойств для обеспечения надежных транзакций базы данных.
Общие спецификации веб-служб включают:
- Безопасность веб-служб (WS-безопасность) : стандартизирует способы защиты и передачи сообщений с помощью уникальных идентификаторов, называемых маркерами.
- WS-ReliableMessaging : Стандартизирует обработку ошибок между сообщениями, передаваемыми через ненадежную ИТ-инфраструктуру.
- Адресация веб-сервисов (WS-адресация) : Упаковывает информацию о маршрутизации в виде метаданных в заголовках SOAP вместо того, чтобы хранить такую информацию глубже в сети.
- Язык описания веб-служб (WSDL) : Описывает, что делает веб-служба, и где эта служба начинается и заканчивается.
Когда запрос данных отправляется в SOAP API, он может быть обработан через любой из протоколов прикладного уровня: HTTP (для веб-браузеров), SMTP (для электронной почты), TCP и другие. Однако после получения запроса возвращаемые SOAP-сообщения должны быть возвращены в виде XML-документов — языка разметки, который читается как человеком, так и машиной. Завершенный запрос к SOAP API не кэшируется браузером, поэтому к нему невозможно получить доступ позже без повторной отправки в API.
Многие устаревшие системы могут по-прежнему придерживаться SOAP, в то время как REST появился позже и часто рассматривается как более быстрая альтернатива в веб-сценариях. REST — это набор рекомендаций, предлагающих гибкую реализацию, тогда как SOAP — это протокол с особыми требованиями, такими как обмен сообщениями XML.
REST API являются легкими, что делает их идеальными для новых контекстов, таких как Интернет вещей (IoT), разработка мобильных приложений и бессерверные вычисления. Веб-службы SOAP предлагают встроенную безопасность и соответствие транзакциям, которые соответствуют многим корпоративным потребностям, но также усложняют их работу. Кроме того, многие общедоступные API, такие как Google Maps API, следуют рекомендациям REST.
Red Hat предлагает модульные, легкие и комплексные решения API с открытым исходным кодом, открытыми стандартами и доступными локально или в облаке. Они играют важную роль в том, как вы можете оптимизировать свои ИТ, чтобы сделать их более гибкими и быстрее приносить пользу.
Нужно знать, что такое интеграция? Узнайте, что это такое, как его внедрить и почему он намного лучше с открытым исходным кодом.
Apache Kafka — это распределенная платформа потоковой передачи данных, которая может публиковать, подписываться, хранить и обрабатывать потоки записей в режиме реального времени.
API означает интерфейс прикладного программирования — набор определений и протоколов для создания и интеграции прикладного программного обеспечения.
Продукты
Комплексный набор технологий интеграции и среды выполнения, разработанных для помощи в создании, развертывании и эксплуатации приложений с учетом требований безопасности и масштабируемости в гибридном облаке.
Размещаемые и управляемые платформы, приложения и службы данных, которые упрощают работу с гибридным облаком, снижая эксплуатационные расходы и сложность доставки облачных приложений.
Набор продуктов, инструментов и компонентов для разработки и поддержки облачных приложений. Включает Red Hat AMQ, Red Hat Data Grid, платформу корпоративных приложений Red Hat JBoss®, веб-сервер Red Hat JBoss, сборку Red Hat OpenJDK, сборку Red Hat Quarkus, набор облачных сред выполнения, набор инструментов для миграции приложений. , единый вход и служба запуска.
Комплексный набор технологий интеграции и обмена сообщениями для соединения приложений и данных в гибридных инфраструктурах. Включает Red Hat 3scale API Management, Red Hat AMQ, Red Hat Fuse, Red Hat Runtimes, сбор измененных данных и реестр служб».0013
Статьи по теме
- Что такое интеграция?
- Что такое реестр служб?
- Что такое сетка событий?
- Что такое Apache Kafka?
- Что такое сбор измененных данных (CDC)?
- Что такое архитектура, управляемая событиями?
- REST и SOAP
- Почему стоит выбрать Red Hat для гибкой интеграции?
- Зачем запускать Apache Kafka в Kubernetes?
- Что такое IDE?
- Понимание промежуточного программного обеспечения
- Что такое промежуточное программное обеспечение?
- Почему стоит выбрать ПО промежуточного слоя Red Hat?
- Понимание API
- Безопасность API
- Что такое API?
- Что делает шлюз API?
- Что такое REST API?
- Что такое дизайн API?
- Что такое управление API?
- Что такое монетизация API?
- Что такое GraphQL?
- Почему стоит выбрать Red Hat для управления API?
Ресурсы
Создайте гибкую инфраструктуру и сделайте организацию адаптивной
Оптимизировать производительность приложений и результаты бизнеса
Материал аналитика
Сетка событий: Primer
DataSheet
Red Hat Fuse: Cloud-Cliate Distribute Integration
Material
Ключевые вопросы.
This entry was posted in Популярное

Posted:

Comments: