Ответ 1

Я постараюсь охватить два случая, с которыми люди могут столкнуться:

Клиентская сторона:

Веб-приложение Google APIs Explorer активно кэширует, поэтому вам нужно будет очистить кэш или выполнить обновление при обновлении серверной части API, чтобы увидеть изменения в клиенте.

Сторона сервера (в приложении Deployment Production App Engine):

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

• Проверьте журналы администратора (https://appengine.google.com/adminlogs?&app_id=s~YOUR-APP-ID) после развертывания. После успешного развертывания кода приложения вы должны увидеть сообщение:

  Completed update of a new default version
  

  и вскоре после этого вы должны увидеть:

  Successfully updated API configuration
  

  Если в этом сообщении указано, что обновление конфигурации API завершилось неудачно, следует выполнить развертывание снова. Если указанная ошибка повторяется, сообщите нам об ошибке. Если вы не видите никакого сообщения о конфигурации API, вам следует убедиться, что путь /_ah/spi/.* явно указан в вашей конфигурации маршрутизации (app.yaml для Python, web.xml для Java).

• Проверьте журналы приложений (https://appengine.google.com/logs?&app_id=s~YOUR-APP-ID) после развертывания. После завершения развертывания инфраструктура API Google делает запрос к /_ah/spi/BackendService.getApiConfigs в вашем приложении, чтобы ваша конфигурация API (как JSON) могла быть зарегистрирована в инфраструктуре API Google и могли быть созданы все связанные с обнаружением конфигурации. Если этот запрос не завершится с 200, ваши изменения API не будут отображаться, так как инфраструктуре Google API нечего регистрировать.

• Если вы постоянно получаете перенаправление 302 для запросов к /_ah/spi/BackendService.getApiConfigs, это потому, что вы (или ваша сгенерированная конфигурация API) указали "адаптер bns", который использует http: в качестве протокола в корне API, но ваш web.xml (Java) или app.yaml (Python) требуется, чтобы пути через /_ah/spi были безопасными. При этом запросы, использующие http: в качестве протокола, будут перенаправлены (используя 302) на ту же страницу с https: в качестве протокола. Это обсуждалось на форуме Trusted Tester перед тем, как перейти в Experimental.

Ответ 2

Вот что случилось со мной.

Я тестировал свою конечную точку на localhost, и она работала нормально.

Я развернул свою конечную точку на appspot, и когда я сделал запросы к ней, я получил в браузере сообщение "Не найдено".

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

Итак, я переделал свою войну с файлом favicon, 404 http-код исчез, и конечная точка отлично работала на appspot тоже!

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

Ответ 3

Я заметил, что если вы впервые загрузили свое приложение без следующего в вашем web.xml:

 <security-constraint>
        <web-resource-collection>
            <url-pattern>/_ah/spi/*</url-pattern>
        </web-resource-collection>
        <user-data-constraint>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

Затем ваш адаптер bns будет установлен как http, идущий вперёд. Когда я добавлю выше, я получаю 302 http-код на /_ah/spi/BackendService.getApiConfigs, и конечные точки никогда не обновляются.

Итак, теперь я вернулся, чтобы не использовать https on/_ah/spi, и мои конечные точки обновляются. Я думаю, для тех, кто видит, что их конечные точки не обновляются, вернутся к первой конфигурации, которую они использовали для ssl on/_ah/spi/.

рыскания.

Ответ 4

У меня была такая же ошибка Not Found (код ошибки 404), когда я вызывал свой API с помощью этого URL

https://MY_APP_ID.appspot.com/_ah/api/MY_SERVICE/v1/user

Я пробовал все и, наконец, исправил его, удалив файлы discovery из WEB-INF и сохранил только MY_SERVICE-v1.api, а затем перераспределил API. Теперь он отлично работает.

Ответ 5

Я также получал устаревший API-интерфейс обнаружения после развертывания новой версии, для GAE потребовалось пару минут, чтобы начать подавать мне новый.

Ответ 6

У меня была та же проблема, и я проверил журналы администратора, другие журналы и т.д., но все же мой API не обновлялся до последней версии.

Итак, я решил проверить код API для последнего метода, который я написал (я пишу на Java 7). И я узнал, что GAE не любит таких утверждений, как:

if (!blocked){ .... }

Я переключил это на:

if (blocked == false) { ... }

И это сработало как шарм. Таким образом, по его мнению, GAE сканирует новые методы API и не принимает некоторые ярлыки.