URL-адрес обратного вызова будет вызван методом API, который вы вызываете после его завершения. Поэтому, если вы вызываете

POST /api.example.com/foo?callbackURL=http://my.server.com/bar

Затем, когда /foo завершено, он отправляет запрос на http://my.server.com/bar. Содержимое и метод этого запроса будут различаться - проверьте документацию по API, к которому вы обращаетесь.

Если вы используете URL обратного вызова, то API может подключиться к URL обратного вызова и отправить или получить некоторые данные. Это означает, что API может подключиться к вам позже (после вызова API).

пример

1. ВЫ отправляете данные, используя запрос к API
2. API отправляет данные, используя второй запрос к вам

Точное определение должно быть в документации API.

Это механизм для вызова API в асинхронном режиме. Последовательность следующая

1. ваше приложение вызывает URL, передавая в качестве параметра URL обратного вызова
2. API отвечает 20x http кодом (201, я думаю, но обратитесь к документации API)
3. API работает по вашему запросу в течение определенного времени
4. API вызывает ваше приложение, чтобы дать вам результаты, по URL-адресу обратного вызова.

Таким образом, вы можете вызвать API и сказать своему пользователю, что запрос "обрабатывается" или "получен", например, а затем обновить статус, когда вы получите ответ от API.

Надеюсь, это имеет смысл. -G

Думайте об этом как письмо. Иногда вы получаете письмо, например, с просьбой заполнить форму, а затем возвращаете форму в конверте с указанным адресом, который находится в оригинальном конверте, в котором была размещена форма.

После того как вы закончили заполнение формы, вы помещаете ее в предоставленный конверт и отправляете обратно.

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

Это полезно, потому что иногда вам могут понадобиться годы, чтобы обработать некоторые данные, и нет смысла заставлять абонента ждать ответа. Например, скажем, ваш API позволяет пользователям отправлять на него документы и проверять их на вирусы. Затем вы отправляете отчет после. Сканирование может занять 3 минуты. Пользователь не может ждать 3 минуты. Таким образом, вы подтверждаете, что получили документ, и позволяете звонящему заниматься другими делами, пока вы выполняете сканирование, а затем используйте callbackUrl, когда закончите, чтобы сообщить им результат сканирования.

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

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

https://example.com/callback?code=AUTHORIZATION_CODE

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