Обходное решение для облачных конечных точек

У нас есть приложение AppEngine, которое мы хотели бы использовать с конечными точками Google. Нам необходимо поддерживать веб-клиента, а также мобильных клиентов, что делает конечные точки привлекательными для нас, поскольку мы можем легко создавать клиентские API для Android и iOS.

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

Вот что мы уже пробовали:

  • Запросы CORS от клиента к домену appspot.com. Проблема с этим заключается в том, что наш запрос не соответствует требованиям для простых CORS (пользовательских заголовков, файлов cookie и т.д.), Запрос предварительной проверки должен быть отправлен с каждым запросом, который замедляет все

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

  • Мы также попытались создать дубликат API Джерси REST только для веб-клиента. Мы удваиваем аннотацию всех наших методов (один раз для Cloud Endpoints и один раз для Джерси), а веб-клиент обращается к API Джерси, а мобильные клиенты получают доступ к API конечных точек. Это работает довольно хорошо, за исключением того, что Jersey и Endpoints используют разные исключения. Поэтому, если мы хотим выбросить исключение 404 Endpoints, которое испортит ответ Джерси и наоборот.

Есть ли другие варианты? Мы хотим использовать возможности конечных точек для создания мобильных клиентов, а также обойти ограничение пользовательского домена для веб-клиента.

ОТВЕТЫ

Ответ 1

Google Cloud Endpoints 2.0 теперь поддерживает пользовательские домены. Если вы используете Google Cloud Endpoints 1.0, вы можете выполнить миграцию, выполнив следующие действия:

  • Обновите свою зависимость, чтобы использовать новый артефакт. В Maven это выглядит что-то вроде ниже:

    com.google.endpoints endpoints-framework 2.0.0-beta.8

  • Удалить устаревшую зависимость, которая является артефактом appengine-endpoints.

  • Обновите точку входа API в файл проекта web.xml:

    • Переименуйте все вхождения SystemServiceServlet в EndpointsServlet.
    • Замените все вхождения пути /_ah/spi/* на новый требуемый путь /_ah/api/*

См:

https://cloud.google.com/appengine/docs/java/endpoints/migrating

https://code.google.com/p/googleappengine/issues/detail?id=9384

Ответ 2

Мы закончили тем, что полностью остановились на конечных точках Cloud, и пошли с использованием чистого API REST Джерси.

Чтобы справиться с нашей потребностью в создании мобильных клиентов для API, мы аннотировали наш API Swagger. Как добавленный бонус, Swagger, похоже, поддерживает больше поколений клиентов, чем Cloud Endpoints, а также упрощает настройку собственного поколения клиентов из шаблона, если ваш целевой язык напрямую не поддерживается.

Джерси + Swagger не так просто настроить как Cloud Endpoints, но он более настраиваемый и позволил нам обойти ограничения пользовательских доменов, наложенные Cloud Endpoints.

Ответ 3

Самое простое решение - использовать обратный прокси. Например, если ваше приложение http://myapp.appspot.com, создайте простую html-страницу на http://myapp.com и перенаправлять на http://myapp.appspot.com с помощью javascript.

Index.html на http://myapp.com.

<html>
   <head>
      <script>
          windows.location = http://myapp.appspot.com;
      </script> 
  </head>
  <body></body>
</html>

У него есть еще одно преимущество: если вы разместите свою прокси-страницу на другом хостинге (а не appspot.com) для своего приложения (http://myapp.appspot.com) будут доступны из Китая.