RESTful 아키텍처의 장단점 [닫기]

REST의 장단점에 대해 내가 본 가장 일반적인 토론은 SOAP에 대한 토론을 구성하는 경향이 있습니다. 나도 경험이 없습니다. 나는 현재 내 경험이 부족하여 평가하기가 어렵다는 결정에 직면 해 있습니다. 몇 가지 구성 요소가있는 응용 프로그램 (주로 소유자가 여러 사이트를 관리 할 수있는 관리 측면)과 사용자가 호스트에 보유한 데이터와 상호 작용할 수있는 공용 사용자 인터페이스를 개발하기 시작했습니다. RESTful 아키텍처를 통해 후자가 어디에서나 호스팅되고 전자와 통신하거나 두 구성 요소가 동일한 호스트에 있어야한다는 의미를 평가해야합니다. RESTful 아키텍처를 개발할 때 특히 다음 영역의 용량과 관련하여 중요한 의미는 무엇입니까?

1 : 보안 2 : 성능 3 : 인터페이스 복잡성

편집 :이 질문에 대한 답변 중 일부를보고-나는 명확히해야합니다. SOAP와의 비교를 찾고 있지 않습니다. 대신 모든 구성 요소가 하나의 호스트에있는 REST 응용 프로그램과 응용 프로그램의 개요입니다. (하지만 그 답변에 감사드립니다!)

이러한 영역을 감안할 때 대략적인 개요를 제공 할 수는 있지만 결론을 이끌어 낼 수는 없습니다. 두 프로토콜이 다른 두 가지 주요 영역이 있습니다.

• 메시지 형식
• 서비스 발견

메시지 형식이 가장 이해하기 쉽습니다. 요청과 응답 모두를위한 SOAP 패키징은 상당히 무겁습니다. 헤더와 본문 섹션이 모두 포함 된 SOAP 엔벨로프가 있습니다. 요청 체인의 여러 필터에서 헤더를 사용하여 일종의 식별, 권한 부여 등을 수행 할 수 있습니다. 그러나 XML을 구문 분석하는 데 비용이 많이 들기 때문에 시스템의 확장성에 특정 페널티를줍니다. 스택의 SOAP 처리 계층에 따라 달라집니다.

서비스 발견은 아마도 가장 많은 경합이있는 곳입니다. 본질적으로 REST는 예측 가능한 엔드 포인트를 제공 하며 요청의 컨텐츠는 단순한 HTTP 요청입니다. 이점은 추가 오버 헤드가 없으며 최종 사용자는 사이트의 URL 구조를 이해 한 후 필요한 작업을 수행하는 방법을 거의 추측 할 수 있다는 것입니다. 물론 순진한 보안 의식이있는 사람들은이를 약점으로 볼 것입니다. 결국 SOAP을 사용하면 엔드 포인트가 무엇인지 알기 위해 WSDL을 사용해야합니다. 물론 SOAP을 사용하면 전체 메시지 형식이 제공되므로보다 표적화 된 공격을 할 수 있습니다.

제공 한 카테고리별로 분류 :

보안

본질적으로 다른 것보다 더 안전하지는 않습니다. 좋은 보안 원칙을 사용하십시오.

• 통신 암호화
• 처리하기 전에 사용자를 인증하고 권한을 부여하십시오
• 직접적인 공격을 피하는 좋은 코딩 습관
• 그리고 그것은 짧은 목록입니다.

모호함을 기억하십시오! = 보안.

공연

단순한 HTTP 프로토콜을 따르는 요청으로 인해 원시 성능과 확장 성이 모두 REST로 이동합니다. 대부분의 SOAP 스택은 SAX 구문 분석 (이벤트 기반 구문 분석)을 사용하여 SOAP 스택의 확장 성을 크게 향상 시키지만 오버 헤드에 상당한 영향을 미칩니다. SOAP에는 XML 구문 분석 오버 헤드 외에 정상적인 HTTP 처리 오버 헤드가 있습니다. REST에는 HTTP 처리 오버 헤드가 있습니다.

복잡성

시스템의 관점에서 보면 REST가 승리합니다. 움직이는 부품 수가 적고 요청 체인이 적습니다. 따라서 신뢰성을 높이기가 더 쉽습니다.

프로그래머의 관점에서, 사용중인 IDE 또는 프레임 워크가이를 잘 지원하면 SOAP가 이길 수 있습니다. 본질적으로 REST를 사용하면 전처리 작업 (인증 / 권한 부여 등)을 수행 할 수 있으며 SOAP를 사용하면 플러그 가능한 처리 체인으로 많은 작업을 수행 할 수 있습니다.

내 취향

HTTP 요청에 매우 익숙하며 웹 작동 방식을 알고 있습니다. 결과적으로 REST 접근법이 나에게 더 바람직합니다. 그러나 나는 내 고객 중 일부가 그 점에 불편하다는 것을 알고 있습니다. REST 대 SOAP 등의 보안을 비난하는 업계 기사를 읽었습니다. 결론은 보안이 보장되지 않는다는 것입니다. 응용 프로그램이 필요한만큼 안전해야합니다. 분명히, 소셜 웹 애플리케이션은 은행이나 정부 시스템만큼 많은 보안을 요구하지 않습니다. 많은 SOAP 스택에는 유사한 보안을 제공하기 위해 플러그 인 할 수있는 프로세서가 포함되어 있지만 여전히 찾아서 배치하는 것은 사용자의 책임입니다.

1. 보안 : HTTPS를 사용하십시오. 이것은 두 가지 모두에 적용됩니다.
2. 성능 : . REST는 CPU 비용이 적게 듭니다 (파싱, 마샬링, 언 래핑 감소). 또한 REST를 사용한 캐싱은 케이크 조각입니다.
3. 복잡성 : REST는 설정 측면에서 훨씬 덜 요구되며 결국 GET / POST입니다. SOAP은 유지 관리하기 위해 훨씬 더 많은 관리가 필요하지만 (wsdl 등) IDE에서 지원하는 경우 조금 더 쉽습니다.

REST와 일부 내용 / mime 유형으로 동일한 작업을 수행 할 수있을 때 SOAP 이 너무 부풀어 오른다 고 생각 합니다. 또한 SOAP는 랩핑 랩핑 (wrrapper-of-wrappers) 특성과 더 일반적이며 HTTP에 국한되지 않기 때문에 많은 오버 헤드를 가져옵니다. IDE가 올바르게 지원하고 HTTP를 배우고 싶지 않은 경우 SOAP은 사용하려고합니다. 그러나 나를 위해 REST는 사용하기가 훨씬 쉽고 웹 친화적입니다.

요즘에는 사용할 REST API가 매우 좋습니다. Java에 익숙하다면 Jax-RS는 정말 멋지다. 일부 사람들의 경우, 이 포르노 같다.

REST의 가장 큰 장점은 RPC 아키텍처에서 벗어나는 것입니다. REST는 프로세스가 아닌 리소스를 노출합니다. 이를 통해 한 부품의 변경, 개선 및 고장이 다른 부품에 부정적인 영향을 미치는 느슨하게 결합 된 시스템을 만들 수 있습니다.

불행히도 REST의 일반적인 오용은 내부 데이터 구조를 노출시키는 것입니다 (최악의 경우 데이터베이스의 CRUD입니다). 즉, 만드는 아주 열심히 안전하게 작업을 수행 할 수 있습니다. '올바른'사용은 처리중인 시스템의 일부와 관련된 높은 수준의 개체를 노출하고 불일치시 오류 상태 코드를 자유롭게 반환하는 것입니다.

REST에서 자주 간과되는 또 다른 부분은 대부분 동사의 dem 등성입니다. GET뿐만 아니라 PUT 및 DELETE도 한 번 또는 여러 번 적용하면 정확히 동일한 결과가되어야합니다 (이미 삭제 된 경우 404를 리턴하지 않거나 클라이언트가 동일한 PUT을 수행하는 경우 '변경 사항 없음'). 이는 의미 체계의 정확한 해석에 대한 강력한 시스템과 상호 의존성을 떨어 뜨립니다.

WS- * 표준은 실제로 RPC over SOAP / HTTP를 실행하는 것에 관한 것입니다. 따라서 CORBA와 J2EE에 대한 모든 생각과 이전 작업은 대부분 XML에서 동일한 종류의 작업을 수행했습니다. 이것은 타입 선언과 서비스 계약, 메타 데이터 교환, 선언적 보안 등과 같은 것을 의미합니다. 솔직히 기업에서도 과도하게 사용되었습니다.

자신과 같은 인터넷 웹 응용 프로그램을 구축하는 사람들은 RESTful 아키텍처를 사용하는 것이 좋습니다. 거의 모든 플랫폼에서 사용하고 있으며 사용중인 사양의 버전과 수많은 도구 별 유형 변환 문제 등을 걱정하지 않고 간단하게 사용할 수 있습니다.

현재 REST 구현에 비해 SOAP의 큰 장점은 SOAP가 더 쉽게 도구화된다는 것입니다. 대부분의 RESTful 클라이언트는 인터페이스를 이해하고 일종의 클라이언트를 작성해야합니다. SOAP의 경우 wsdl.exe를 가리키고 클래스가 생성됩니다.