REST에서 웹 서비스를 구현하려고합니다.
저는 대륙간 연결에서 패킷 손실로 인해 때때로 느리고 불안정한 큰 문제가 있습니다.느리고 불안정한 인터넷 연결 - SOAP 대 REST
저는 양쪽, 클라이언트 및 서버를 제어합니다. 초당 여러 번 서버에 호출을 수행하는 클라이언트. 때로는이 인터넷 문제를 해결하기 위해 더 많은 데이터를 하나의 연결로 보냅니다.
REST와 SOAP의 차이점에 대해 많이 읽었으며 SOAP 봉투가 REST 데이터보다 큽니다.
내 질문은 둘 다 http를 넘기 때문에 둘 사이의 데이터 크기 외에 다른 차이점이 있습니까? 사용 하시겠습니까?
당신이 암시했듯이 SOAP 대 REST의 문제는 아니지만 메시지 크기와 메시지 빈도의 문제입니다.
프로토콜 (메시지의 개수와 빈도 및 패턴)이 REST와 SOAP에서 동일하면 유일한 차이점은 메시지 크기입니다. 그러나 진정한 RESTful 시스템 설계는 SOAP 버전과 동일한 통신 패턴을 가질 수 없다. 왜냐하면 REST는 엔드 포인트의 메소드에 대한 메시지보다는 Resource를 조작하기 때문이다. REST는 SOAP과 달리 표준 동사 (PUT, POST, GET, DELETE)의 통일 된 집합을 사용합니다. 당신의 디자인에 대해 더 많이 알지 못해 더 말하기가 어렵습니다.
"올바른"해결책은 대기 시간 (개별 메시지에 초점을두고 있음) 또는 처리량을 평가하는지 여부에 따라 다릅니다. 각 호출이 성공할 확률을 높이려면 (즉, 대기 시간을 높이십시오), 패킷 수가 적 으면 작을수록 좋지만 SOAP 메시지도 상대적으로 작 으면이 경우가 아닐 수 있습니다. 처리량의 경우 SOAP 대 REST에 관계없이 메시지를 함께 배치하는 것이 좋습니다.
this question에 대한 답변도 유용 할 수 있습니다.
마지막으로, REST는 아키텍처이고 SOAP은 프로토콜 인 반면 REST는 HTTP를 사용해야한다는 것을 지정하지 않으며 페이로드 형식도 지정하지 않습니다. 따라서 REST 구현은 일반적으로 더 작은 메시지를 갖지만 보장되지는 않습니다.
두 가지 차이점 중 하나는 메시지가 도착하고 올바른 순서로 도착하도록하는 프로토콜을 만드는 WS-ReliableMessaging 표준 (WCF에서 구현 됨)이 있다는 것입니다. 손실이 많은 네트워크에서도 안정적인 메시지 전달이 요구된다면 SOAP over REST의 장점은 입니다.
SOAP 인터페이스는 RESTful으로 만들 수 있으므로 SOAP과 최소한의 프로토콜 (XML 또는 JSON, enveloppe)에 대해 생각하고 있다고 가정합니다.
당신이 지적한 주요 기술적 요소는 메시지의 크기입니다. 'Custom'REST는 페이로드와 헤더를 원하는대로 정확하게 디자인 할 수있는 유연성을 제공하며 SOAP 인 벨롭은 작은 빈번한 메시지에 단순한 크기를 추가 할 수 있습니다.
주관적으로 SOAP 라이브러리는 주, 세션, 비 멱등 조작 또는 다른 비 RESTful 패턴에 의존하게 만듭니다. 이는 귀하의 경우에 책임이됩니다. 유혹을 거부 할 수는 있지만 세션이없는 JSF를 시도하는 것과 같다. 코드의 모든 부분에서 다시 돌아온다.
전체적으로 REST를 사용합니다.
즉, 메시지가 크고 전달되어야 할 경우 SOAP에 이점이있을 수 있습니다. 개인적으로 나는 그것이 사라질 수있을 때 작은 상태없는 멱등수 및 비 트랜잭션 메시지로 "일회용 클라이언트, 서버 및 네트워크"샷건 접근 방식을 좋아하지만 프로토콜 디자인을 더욱 중요하게 만듭니다.