그러나 오늘날 REST에 대한 흥미로운 데모에 참석했지만 REST가 SOAP 기반 서비스 스택보다 사용 및 구현하는 것이 더 낫거나 단순한 단일 이유 (또는 제시되지 않은)를 생각할 수 없었습니다.
"실제"사용자가 SOAP 기반 서비스 대신 REST를 사용하는 이유는 무엇입니까?
답변:
적은 오버 헤드 (모든 호출을 래핑 할 SOAP 엔벨로프 없음)
덜 중복 (HTTP는 이미 SOAP 봉투에 표시되어야하는 DELETE, PUT, GET 등의 작업을 나타냅니다).
보다 표준화 된-HTTP 작업은 잘 이해되고 일관되게 작동합니다. 일부 SOAP 구현은 까다로울 수 있습니다.
더 읽기 쉽고 테스트 가능 (브라우저만으로 SOAP를 테스트하기가 더 어렵다).
XML을 사용할 필요는 없습니다 (SOAP도 필요하지 않지만 이미 봉투를 파싱하고 있기 때문에 이해가되지 않습니다).
라이브러리는 SOAP (종류)를 쉽게 만들었습니다. 그러나 내가 지적한 것처럼 많은 중복성을 추상화하고 있습니다. 그렇습니다. 이론상 SOAP은 다른 전송을 통해 비슷한 일을하는 계층의 꼭대기에 올라가지 않도록 할 수 있지만 실제로는 거의 모든 SOAP 작업이 HTTP를 통해 이루어집니다.
RESTful 서비스는 SOAP 보다 훨씬 간단합니다. 기반 (일반) 서비스 합니다. 그 이유는 REST가 일반 HTTP 요청을 기반으로하기 때문에 요청 유형 (GET = 검색, POST = 쓰기, DELETE = 제거 등)에서 의도를 유추 할 수 있고 완전히 상태가 없기 때문입니다. 반면에 요청 컨텍스트가 포함 된 메시지 봉투의 개념과는 달리 유연성이 떨어질 수 있습니다.
내 경험상 SOAP는 기업 내 서비스에 선호되었고 REST는 퍼블릭 API로 노출 된 서비스에 선호되었습니다.
.NET 프레임 워크에 WCF와 같은 도구를 사용하면 서비스를 REST 또는 SOAP로 구현하는 것이 매우 간단합니다.
관련 독서 :
REST는 구현에 구애받지 않고 훨씬 투명하므로 공개 API, 특히 Flickr, Amazon 또는 Digg와 같은 API를 마케팅 도구로 사용하고 사람들이 실제로 데이터를 소비하기를 원하는 대형 웹 사이트에 적합합니다. 그들은 선택한 스크립팅 언어의 버그가있는 SOAP 라이브러리를 디버깅하려고하는 1000 명의 초보자 개발자를 손에 들고 싶지 않습니다 .
SOAP 및 WSDL과 대립 라이브러리 및 양쪽에 알려진 실마리가있는 내부 응용 프로그램에 더 좋습니다. (그리고 인터넷 규모의로드 밸런싱, HTTP 캐싱 등과 같은 것을 신경 쓸 필요가 없습니다.) 그런 다음 자체 문서화 된 API를 얻고 작업없이 제로 유형을 보존하십시오.
Steve Vinoski의 블로그 와 그의 최신 기사 는 확실히 가치가 있습니다. 그는 전 CORBA 전문가이며 Michi Henning의 주제 인 "C ++을 사용한 고급 CORBA® 프로그래밍" 에 대한 최고의 책을 썼을 것입니다 . 그러나 그는 이후 클라이언트 / 서버 방식의 오류를보고 REST에 의해 맹세합니다.
REST는 기본적으로 웹 서비스를 구현하는 방법입니다. 적중하려는 웹 서비스를 쿼리하기 위해 HTTP를 올바르게 사용하는 방법 일뿐입니다.
http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer
매우 간단하고 날씬합니다. http 동사를 통해 브라우저로 할 수 있습니다 : GET. 브라우저가 수동으로 일반적인 http POST 요청을 쉽게 수행 할 수 없다는 것을 알지 못했습니다.
하나의 데이터 포인트가 있습니다. Amazon은 REST 및 SOAP 형식으로 API를 제공하며 사용량의 85 %는 REST입니다.
REST는 구현하기 쉽고 이해하기 쉬우 며 고성능입니다.