Android, GWT 및 App Engine : Cloud Endpoints와 GWT RPC?

Question

클라이언트 - 서버 통신을 위해 GWT RPC 메커니즘을 사용하여 GWT + GAE 앱을 defeloped했습니다. 이제 Android 앱에서 제공되는 일부 서비스를 통합하려고합니다. 그러나이 구현이 더 이상 권장되지 않으며 GPE 3.0 (google eclipse plugin)에서 제거되어 클라우드 종점이 이제 사용됨을 발견했습니다 (RPC tooling not available for appengine connected android project for GPE 3.2?).

Cloud Endpoints를 사용할 때 클라이언트 - 서버 통신 솔기를 구현하는 데 필요한 코드가 (적어도 최소한) Cloud Endpoints를 사용할 때 필요하기 때문에이 방법이 채택 된 이유는 무엇이며 (다른 하나는 갑자기 제거되었습니다) 알고 싶습니다. GWT의 RPC에서는 새 클래스를 추가하기가 매우 쉽습니다.이 코드는 매우 쉽게 확장 할 수 있습니다.

왜 Cloud Endpoint가 GWT RPC보다 나은가요? 이 두 가지 접근 방식의 장단점은 무엇입니까?

Answer 1

개인적인 의견 : 그들은 독점적이고 불투명하기 때문에 둘 다 빨기도합니다. Google은 훌륭한 엔지니어링 회사이지만이 두 가지는 IMO 모두 실수입니다. 개발자들이 독점적 인 API에 묶고 싶었던 것 같습니다. 1990 년대 MS였습니다.

REST + JSON을 사용합니다. 내 개인 즐겨 찾기는 RESTEasy + Jackson이며 완벽하게 GAE에서 작동합니다.

장점 :

1. 유연한 serialising : 잭슨 클래스와 JSON (멀티 - 일, 임베디드, 게터/세터 등), 당신은 또한 사용자 정의 시리얼 라이저를 작성할 수 사이의 고급 매핑을 만들 수 있습니다.
2. 스택의 모든 권한 : 다른 구성으로 여러 끝점 (예 : 공개/비공개)을 가질 수 있으며 요청을 가로 채고 확장 할 수도 있습니다 (사용자 지정 예외를 throw 함 -> RESTEasy는 응답으로 사용자 지정 JSON을 만듭니다)
3. 인터셉터는 표준 또는 사용자 정의 인증 체계의 사용을 허용
4. 완전 개방 소스 화 및 사용하여 표준 프로토콜과 직렬화 형식 : 브라우저에서 무슨 일이 일어나고 있는지 검사하기 쉬운
5. 휴대용 : 모든 서블릿 기반의 서버와 클라이언트에서 작동합니다 (브라우저 , Android, iPhone 등)

부여 된 학습 곡선은 조금 높지만 적어도 당신은 제어 할 수 있습니다.

Answer 2

GWT/RPC와 비교하여 클라우드 종점 (및 다른 REST/JSON 기반 솔루션)의 장점은 언어에 무관하다는 것입니다. 클라우드 엔드 포인트의 경우 Google 툴은 Android, 웹 및 iOS를 직접 지원하지만 인터페이스에 대한 설명을 생성하므로 해당 설명을 사용할 수있는 모든 기술을 지원할 수도 있습니다.

끝점을 사용하면 OAUTH 인증을 비교적 쉽게 할 수 있지만 GWT와 비교하는 방법에 대해서는 언급 할 수 없습니다.