Избранное | Русский | Войти

Обзор API Java для получения данных по URL

Приложения App Engine могут взаимодействовать с другими приложениями или обращаться к сторонним ресурсам в Интернете путем получения данных по URL-адресам. Для отправки HTTP- и HTTPS-запросов и получения ответов на них приложение может использовать службу URL Fetch. Служба URL Fetch использует сетевую инфраструктуру Google в целях масштабирования и повышения эффективности.

Получение данных по URL с помощью java.net

Чтобы устанавливать HTTP- и HTTPS-соединения из приложения Java, можно использовать класс java.net.URLConnection и связанные с ним классы из стандартной библиотеки Java. App Engine реализует этот интерфейс с помощью службы получения данных по URL. Приложение не выполняет сокет-соединения напрямую.

Проще всего получить содержание страницы по URL, создав объект java.net.URL и вызвав метод openStream(). Этот метод обрабатывает создание соединения, выполнение запроса HTTP GET и получение данных ответа.

import java.net.MalformedURLException;
import java.net.URL;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.IOException;

// ...
        try {
            URL url = new URL("http://www.example.com/atom.xml");
            BufferedReader reader = new BufferedReader(new InputStreamReader(url.openStream()));
            String line;

            while ((line = reader.readLine()) != null) {
                // ...
            }
            reader.close();

        } catch (MalformedURLException e) {
            // ...
        } catch (IOException e) {
            // ...
        }

Для более сложных запросов можно вызывать метод openConnection() объекта URL, чтобы получить объект URLConnection (HttpURLConnection или HttpsURLConnection в зависимости от URL). До выполнения запроса в этот объект можно добавить дополнительные сведения. См. статью Использование java.net.

Выполнение запросов

Приложение может получить данные по URL-адресу, используя протокол HTTP (обычный) или HTTPS (безопасный). В URL-адресе указывается схема, которую следует использовать: http://... или https://...

URL должен использовать стандартные порты для протоколов HTTP (80) и HTTPS (443). Порт определяется используемой схемой, но может также входить в состав URL-адреса, если является стандартным для данной схемы (https://...:443/). Приложение не может ни подключиться к удаленному хосту через произвольный порт, ни использовать нестандартный для схемы порт.

Функция fetch может использовать один из следующих HTTP-методов: GET (часто используется для запроса веб-страниц и данных), POST (часто используется для отправки веб-форм), PUT, HEAD и DELETE. Запрос на получение данных может содержать заголовки HTTP-запроса и информационное наполнение (тело HTTP-запроса).

Чтобы получить результат, служба URL Fetch использует прокси-сервер, совместимый с HTTP/1.1.

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

Служба URL Fetch вызывается синхронно, и ответ возвращается только после получения ответа от удаленного хоста. Время ожидания, заданное для запроса вашего приложения, может истечь прежде, чем ответ от удаленного хоста будет получен. Отменить запрос после отправки невозможно.

Безопасные соединения и HTTPS

Для получения данных по URL с безопасных серверов приложение может использовать протокол HTTPS. Запрос и данные ответа передаются по сети в зашифрованной форме.

Прокси-сервер, используемый службой URL Fetch, не может аутентифицировать хост, к которому обращается. Поскольку использование цепи доверия сертификатов не предусмотрено, прокси-сервер принимает все сертификаты, включая самоподписанные. При использовании HTTPS прокси-сервер не может распознать атаки типа "человек посередине" между App Engine и удаленным хостом.

Заголовки запросов

Приложение может задавать HTTP-заголовки для исходящих запросов.

Если заголовок Content-Type не задан явным образом, то при отправке HTTP-запроса POST он приравнивается к x-www-form-urlencoded. Это тип содержания, используемый веб-формами.

В целях безопасности приложение не может изменять следующие заголовки:

  • Content-Length
  • Host
  • Referer
  • Vary
  • Via
  • X-Forwarded-For

App Engine присваивает этим заголовкам соответствующие точные значения. Например, App Engine определяет заголовок Content-Length из данных запроса и добавляет его к запросу перед отправкой.

Ответы

Служба URL Fetch возвращает все данные ответа, включая код, заголовок и тело ответа.

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

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

Обращение к хостам, защищенным корпоративным брандмауэром

С помощью Google Secure Data Connector (SDC) ваше приложение может подключаться к системам, защищенным вашим корпоративным брандмауэром. После настройки агента SDC в вашей сети приложения App Engine, работающие в домене Служб Google, смогут выполнять с его помощью аутентификацию и осуществлять доступ к URL-адресам вашей сети интранет. Агент SDC гарантирует, что только ваши приложения смогут подключаться к вашей сети интранет и только для пользователей, выполнивших вход в ваш домен с помощью аккаунта Служб Google.

С помощью службы URL Fetch ваше приложение может получать доступ к URL-адресам в интранет. Приложение включает в свой запрос специальный заголовок, в котором указывается, что запрос предназначен для агента SDC. Этот заголовок имеет название use_intranet и значение yes. Других изменений не требуется; верификация пользователей, аутентификация и безопасное соединение выполняются автоматически.

Вот пример использования службы получения данных по URL с заголовком use_intranet с помощью интерфейса java.net.HttpURLConnection:

import java.net.HttpURLConnection;
import java.net.URL;

// ...
        URL url = new URL("http://www.corp.example.com/sales.csv");
        HttpURLConnection connection = (HttpURLConnection) url.openConnection();
        connection.setRequestProperty("use_intranet", "true");

Дополнительную информацию можно найти на веб-сайте Google Secure Data Connector.

URL Fetch и сервер разработки

При выполнении приложения на сервере разработки на вашем компьютере вызовы службы URL Fetch обрабатываются локально. Сервер разработки получает данные с URL-адресов, подключаясь к удаленным хостам непосредственно с вашего компьютера и используя при этом ту же конфигурацию сети, которую компьютер использует для доступа в Интернет.

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

Если для доступа к URL-адресам интранет ваше приложение использует Google Secure Data Connector, тестируйте приложение, когда оно подключено к сети интранет, защищенной брандмауэром. В отличие от App Engine, сервер разработки не использует агент SDC для разрешения URL-адресов интранет. Выполнять аутентификацию с помощью агента SDC могут только Службы Google и App Engine.

Квоты и ограничения

Каждый запрос URL Fetch учитывается относительно квоты вызовов API получения данных по URL.

Данные, отправляемые в HTTP- или HTTPS-запросах с помощью службы URL Fetch, учитываются относительно следующих квот:

  • Исходящий трафик (регулируется)
  • Данные, отправленные службой URL Fetch

Помимо этих квот, данные, отправляемые в HTTPS-запросах, также учитываются относительно следующей квоты:

  • Безопасный исходящий трафик (регулируется)

Данные, получаемые в ответ на HTTP- или HTTPS-запросы с помощью службы URL Fetch, учитываются относительно следующих квот:

  • Входящий трафик (регулируется)
  • Данные, полученные службой URL Fetch

Помимо этих квот, данные, получаемые в ответ на HTTPS-запросы, также учитываются относительно следующей квоты:

  • Безопасный входящий трафик (регулируется)

Подробнее о квотах рассказано в разделе Квоты и в разделе Консоли администрирования "Сведения о квотах".

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

Ограничение Величина
Размер запроса 1 мегабайт
Размер ответа 1 мегабайт