Punkty końcowe w chmurze GAE - aktualizacja Api po wdrożeniu

Question

Zaczynam używać punktów końcowych w chmurze w moim projekcie GAE, ale mam problemy z api, które nie są aktualizowane na serwerze.

• localhost: 8888/_ah/api/explorer jest ok.

Ale kiedy wdrażam, nic się nie zmienia.

• myapp.appspot.com:8888/_ah/api/explorer jest złe

Dalsze dochodzenie pokazuje aktualizację punktów końcowych url przykład: https://myapp.appspot.com/_ah/api/myapp/v1/foo/list

Ale ładowane api klient jest nadal błędny. przykład: gapi.client.load ("myapp", "v1", wywołanie zwrotne, URL); gapi.client.myapp.foo.list();

Jeśli zmieniłem połączenie z foo/list na foo/list2, reszta adresu URL zaktualizuje się, pakiet api nie będzie.

Answer 1

Postaram się pokrycie dwa przypadki osób, może uruchomić się:

Side Klient:

Aplikacja Google APIs Explorer internetowych agresywnie buforuje, więc trzeba wyczyścić pamięć podręczną lub wymusić odświeżany po aktualizujesz stronę serwera API, aby zobaczyć zmiany w kliencie.

Server Side (W Rozmieszczone Production App App Engine):

Jeśli masz problemy z wdrażaniem, istnieją dwa miejsca wyglądają podczas debugowania:

• Sprawdź dzienników administratora (https://appengine.google.com/adminlogs?&app_id=s~YOUR-APP-ID) po wdrożeniu. że powinieneś zobaczyć

  Completed update of a new default version 
  

  i wkrótce po: Po udanej rozmieszczenia kodzie aplikacji, powinieneś zobaczyć komunikat

  Successfully updated API configuration 
  

  Jeśli ten komunikat wskazuje, że zmiana konfiguracji API nie powiodła się, należy wdrożyć ponownie. Jeśli błąd jest trwały, powiadom nas o błędzie. Jeśli nie widzisz żadnej wiadomości o konfiguracji API, sprawdź, czy ścieżka /_ah/spi/.* jest jawnie wymieniona w konfiguracji routingu (app.yaml dla Python, web.xml dla Java).

• Sprawdź dzienniki aplikacji (https://appengine.google.com/logs?&app_id=s~YOUR-APP-ID) po wdrożeniu. Po zakończeniu wdrożenia infrastruktura interfejsu API Google przesyła żądanie do aplikacji /_ah/spi/BackendService.getApiConfigs, aby konfiguracja interfejsu API (jako JSON) mogła zostać zarejestrowana za pomocą infrastruktury interfejsu API Google, a następnie można utworzyć wszystkie konfiguracje związane z odnajdywaniem. Jeśli to żądanie nie zostanie uzupełnione o 200, zmiany interfejsu API nie będą się pojawiać, ponieważ infrastruktura interfejsu API Google nie będzie wymagać rejestracji.

• Jeśli konsekwentnie coraz 302 przekierowanie żądań do /_ah/spi/BackendService.getApiConfigs, to dlatego, że (lub generowane API config) została określona „adapter BNS”, który używa http: jako protokół w katalogu głównym API, ale twój web.xml (Java) lub app.yaml (Python) jest wymagane, aby ścieżki przez /_ah/spi były bezpieczne. Spowoduje to wysłanie żądania przy użyciu http:, gdy protokół zostanie przekierowany (przy użyciu 302) na tę samą stronę z https: jako protokołem. To było discussed na forum Zaufanych testerów, zanim przejdziesz do wersji eksperymentalnej.

Answer 2

Zauważyłem, że jeśli przesłać swoją aplikację po raz pierwszy bez następujących w 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> 

Następnie adapter BNS zostanie ustawiony jako http przyszłości. Kiedy dodaję powyższe, otrzymuję 302 kod http na /_ah/spi/BackendService.getApiConfigs, a punkty końcowe nigdy się nie aktualizują.

Tak więc wróciłem, aby nie używać https w/_ah/spi, a moje punkty końcowe są aktualizowane. Myślę, że dla tych, którzy widzą, że ich punkty końcowe nie są aktualizowane, powracają do pierwszej konfiguracji, którą mieli dla ssl na/_ah/spi /.

Yaw.

Answer 3

To właśnie mi się przydarzyło.

Przetestowałem mój punkt końcowy na localhost i działało dobrze.

Zainstalowałem mój punkt końcowy w appspot i kiedy wysłałem do niego żądania, otrzymałem w przeglądarce komunikat "Nie znaleziono".

Spojrzałem więc w dzienniki i kiedy wysłałem żądania do punktu końcowego, zobaczyłem kod błędu http 404 na pliku favicon. A w efektach zapomniałem umieścić ten plik w moim wdrożeniu.

Więc przeniosłem moją wojnę z plikiem favicon, kod http 404 zniknął, a punkt końcowy działał dobrze również na appspocie!

Zdaję sobie sprawę, że może to zabrzmieć głupio, ale to właśnie przeżyłem. (Przepraszam za mój słaby angielski)

Answer 4

Miałem ten sam błąd Not Found (kod błędu 404), kiedy dzwoni mój API za pomocą tego adresu URL

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

próbowałem wszystkiego i wreszcie poprawiony poprzez usunięcie odkrycie plików z WEB-INF i przechowywane tylko MY_SERVICE-v1.api a następnie przesunięte API. Teraz działa dobrze.

Answer 5

Po wprowadzeniu nowej wersji również otrzymywałem nieczytelny dokument z zakresu wykrywania interfejsu API, a GAE potrzebowało kilku minut, aby rozpocząć udostępnianie nowego.

Answer 6

Miałem ten sam problem i sprawdziłem dzienniki administratora, inne dzienniki itp., Ale nadal mój interfejs API nie aktualizował się do najnowszej wersji.

Postanowiłem więc sprawdzić kod API dla ostatniej metody, którą napisałem (piszę w języku Java 7). I okazało się, że GAE nie lubi stwierdzenia typu:

if (!blocked){ .... } 

że przeszedłem do:

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

i to działało jak czar. W związku z tym GAE skanuje nowe metody API i nie przyjmuje niektórych skrótów.