[SPRING] GWT 애플리케이션을위한 REST 백엔드를 빌드해야합니까?

GWT 애플리케이션을위한 REST 백엔드를 빌드해야합니까?

새로운 애플리케이션을 계획 중이며 GWT를 가능한 프론트 엔드로 실험 해 왔습니다. 내가 직면하고있는 디자인 문제는 이것입니다.

내가 사용해야 할 것인가? 옵션 A : GWT-RPC와 신속한 앱 구축

옵션 B : 모든 훌륭한 @Controller, @Service, @Repository 주석을 사용하여 Spring MVC 3.0을 사용하여 REST 백엔드를 빌드하고 GWT 오버레이 기능과 GWT 요청 빌더를 사용하여 백엔드와 통신하는 클라이언트 측 라이브러리를 빌드 하시겠습니까?

나는 이런 유형의 디자인에 대한 모든 장단점과 사람들의 경험에 관심이 있습니까?

해결법

1. ==============================

   1."서버 측 인터페이스를 GWT가 아닌 프런트 엔드와 재사용해야합니까?"라는 질문에 스스로에게 질문하십시오.

   "서버 측 인터페이스를 GWT가 아닌 프런트 엔드와 재사용해야합니까?"라는 질문에 스스로에게 질문하십시오.

   대답이 "아니오, GWT 클라이언트 만있을 것"인 경우 : GWT-RPC를 사용하여 서버 및 클라이언트 측에서 Java 객체를 사용할 수 있다는 이점을 활용할 수 있습니다. 또한 적어도 와 함께 사용하면 통신을 좀 더 효율적으로 수행 할 수 있습니다.이 경우 유형 이름을 작은 숫자 값으로 줄입니다. 또한 예외 처리 (exception) 사용, 타입 안전성 (type safety) 등의 더 나은 오류 처리 기능을 이용할 수 있습니다.

   대답이 "예"이면 여러 서비스 프론트 엔드에서 내 서비스에 액세스 할 수있게 할 것입니다. JSON (또는 XML)과 함께 REST를 사용할 수 있으며 GWT가 아닌 클라이언트도 이해할 수 있습니다. 클라이언트를 전환하는 것 외에도 앞으로는 다른 서버 구현 (Java가 아닌)으로 쉽게 전환 할 수 있습니다. 단점은 GWT 클라이언트 측에서 래퍼 (JavaScript Overlay Types) 또는 변환 코드를 작성하여 JSON 객체에서 멋진 Java 객체를 작성해야 할 필요가 있다는 것입니다. 새 버전의 서비스를 배포 할 때 특히주의해야합니다. 그러면 유형 안전성이 결여됩니다.

   물론 세 번째 옵션은 두 가지를 모두 만드는 것입니다. 공용 REST 인터페이스가 GWT-RPC 인터페이스와 다른 경우라면이 옵션을 선택하십시오. 어쩌면 사용하기 쉬운 서비스의 서브 세트만을 제공 할 수도 있습니다.

2. ==============================

   2.RestyGWT 프로젝트를 사용할 경우 두 가지 작업을 모두 수행 할 수 있습니다. GWT-RPC를 사용하는 것처럼 REST 기반 JSON 리소스를 쉽게 호출 할 수있다. 또한 일반적으로 클라이언트 측의 서버 측에서 동일한 요청 응답 DTO를 재사용 할 수 있습니다.

   RestyGWT 프로젝트를 사용할 경우 두 가지 작업을 모두 수행 할 수 있습니다. GWT-RPC를 사용하는 것처럼 REST 기반 JSON 리소스를 쉽게 호출 할 수있다. 또한 일반적으로 클라이언트 측의 서버 측에서 동일한 요청 응답 DTO를 재사용 할 수 있습니다.

3. ==============================

   3.Spiffy UI 프레임 워크를 만들 때도 동일한 문제가 발생했습니다. 우리는 REST를 선택했고 결코 돌아 가지 않을 것입니다. 심지어 GWT-RPC가 GWT Anti-pattern이라고 말하고 싶습니다.

   Spiffy UI 프레임 워크를 만들 때도 동일한 문제가 발생했습니다. 우리는 REST를 선택했고 결코 돌아 가지 않을 것입니다. 심지어 GWT-RPC가 GWT Anti-pattern이라고 말하고 싶습니다.

   REST는 REST 엔드 포인트를 노출시키지 않으려는 경우에도 좋은 아이디어이다. REST API를 만들면 UI가 빨라지고 API가 향상되며 전체 애플리케이션을 유지 관리 할 수 ​​있습니다.

4. ==============================

   4.REST 아키텍처 스타일은 요청시 코드를 통해 검사 가능한 메시지 (디버깅 및 보안 지원), API 발전, 다중 플랫폼, 단순 인터페이스, 장애 복구, 높은 확장 성 및 확장 가능한 시스템을 촉진합니다. 전체 네트워크 효율성을 위해 상호 작용 별 성능을 교환합니다. 일관된 응용 프로그램 동작에 대한 서버의 제어가 줄어 듭니다.

   REST 아키텍처 스타일은 요청시 코드를 통해 검사 가능한 메시지 (디버깅 및 보안 지원), API 발전, 다중 플랫폼, 단순 인터페이스, 장애 복구, 높은 확장 성 및 확장 가능한 시스템을 촉진합니다. 전체 네트워크 효율성을 위해 상호 작용 별 성능을 교환합니다. 일관된 응용 프로그램 동작에 대한 서버의 제어가 줄어 듭니다.

   "RPC 스타일"(REST와 반대 됨)은 플랫폼의 균일 성, 인터페이스 가변성, 코드 생성을 촉진하므로 네트워크가 존재하지 않지만 허세를 참조 할 수 있으며 사용자 정의 된 상호 작용이 가능합니다. 높은 상호 작용 성능을 위해 전반적인 네트워크 효율성을 트레이드합니다. 일관된 응용 프로그램 동작에 대한 서버의 제어를 향상시킵니다.

   응용 프로그램에서 이전 품질을 원하면 REST 스타일을 사용하십시오. 후자가 필요하면 RPC 스타일을 사용하십시오.

5. ==============================

   5.나는 REST 백엔드를 빌드한다고 말할 것이다. 지난 몇 달 동안 GWT-RPC를 사용하여 개발 한 마지막 프로젝트에서 빠른 부트 스트래핑을 원했습니다. 나중에 REST API가 필요할 때 리팩토링을 수행하는 데 너무 많은 비용이 들고 두 개의 백엔드 API (REST 및 RPC)

   나는 REST 백엔드를 빌드한다고 말할 것이다. 지난 몇 달 동안 GWT-RPC를 사용하여 개발 한 마지막 프로젝트에서 빠른 부트 스트래핑을 원했습니다. 나중에 REST API가 필요할 때 리팩토링을 수행하는 데 너무 많은 비용이 들고 두 개의 백엔드 API (REST 및 RPC)

   클라이언트 측에서 적절한 REST 백엔드 및 비 직렬화 인프라를 구축하면 (json \ xml을 GWT Java 객체로 변환하는 경우) RPC의 이점은 거의 없습니다.

   REST 접근법의 또 다른 장점은 클라이언트가 실행되는 브라우저가 더 자연 스럽다는 것입니다. RPC는 모든 요청이 POST를 사용하는 propitiatory 프로토콜입니다. 표준 방식으로 리소스를 읽을 때 클라이언트 측 캐싱의 이점을 누릴 수 있습니다.

   응답은 코멘트입니다. RPC 프로토콜에 관해서는, 파이어 버그를 사용하여 마지막으로 "킁킁"했을 때 json처럼 보이지 않으므로 그것에 대해 알지 못합니다. 비록 json 기반이라 할지라도 여전히 서버와 통신하는 데 HTTP POST 메서드 만 사용하므로 캐싱에 대한 나의 요점은 여전히 ​​유효합니다. 브라우저는 POST 요청을 캐시하지 않습니다.

   회고전 및 더 잘 수행 할 수 있었던 것에 대해 리소스 지향 아키텍처에 RPC 서비스를 작성하면 나중에 REST 로의 포팅이 쉬워 질 수 있습니다. REST에서는 대개 기본 CRUD 작업을 통해 리소스를 노출하므로 RPC 서비스를 작성할 때 그 접근 방법에 초점을두면 잘 수행해야합니다.

6. ==============================

   6.서버 측에서 Hibernate / JPA를 사용하여 관계형 데이터를 가진 결과 POJO를 클라이언트 (즉, 콜렉션을 가진 Employee 객체)로 보내는 것을 계획하고 있다면 확실히 REST 구현으로 가라.

   서버 측에서 Hibernate / JPA를 사용하여 관계형 데이터를 가진 결과 POJO를 클라이언트 (즉, 콜렉션을 가진 Employee 객체)로 보내는 것을 계획하고 있다면 확실히 REST 구현으로 가라.

   한 달 전에 GWT RPC를 사용하여 GWT 프로젝트를 시작했습니다. 모든 것이 좋았습니다. 일대 다 관계가있는 기본 db의 객체를 직렬화하려고 시도하기 전까지는 좋았습니다. 그리고 두려워하게했다 :

   com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentList' was not included in the set of types which can be serialized by this SerializationPolicy
   

   이 문제가 발생하여 GWT RPC에 머물고 싶다면 다음과 같이 사용해야합니다 :

   나는 지금 RestyGWT를 사용하고있다. 스위치는 꽤 고통 스러웠고 POJO는 문제없이 연재했다.

7. ==============================

   7.나는 이것이 총 응용의 범위에 달려 있다고 말할 것이다. 백엔드가 다른 클라이언트에 의해 사용되어야한다면, 확장 가능해야하고 그런 다음 REST를 사용하여 별도의 모듈을 생성해야합니다. 백엔드가이 클라이언트에서만 사용되는 경우 GWT-RPC 솔루션으로 이동하십시오.

   나는 이것이 총 응용의 범위에 달려 있다고 말할 것이다. 백엔드가 다른 클라이언트에 의해 사용되어야한다면, 확장 가능해야하고 그런 다음 REST를 사용하여 별도의 모듈을 생성해야합니다. 백엔드가이 클라이언트에서만 사용되는 경우 GWT-RPC 솔루션으로 이동하십시오.

from https://stackoverflow.com/questions/4906369/should-i-build-a-rest-backend-for-gwt-application by cc-by-sa and MIT license