Netflix 또는 Twitter 스타일 웹 서비스가 REST 또는 SOAP를 사용해야합니까? [닫은]

Twitter와 Netflix라는 두 가지 REST 서비스를 구현했습니다. 두 가지 모두 SOAP 대신 REST로 이러한 서비스를 공개하기로 한 결정과 관련된 사용 및 논리를 찾기 위해 고심했습니다. 누군가 내가 누락 된 것을 알아낼 수 있고 REST가 이러한 서비스의 서비스 구현으로 사용 된 이유를 설명 할 수 있기를 바랍니다.

1. REST 서비스를 구현하는 데 SOAP 서비스를 구현하는 것보다 시간이 오래 걸립니다. 모든 현대 언어 / 프레임 워크 / 플랫폼이 WSDL에서 읽고 프록시 클래스와 클라이언트를 출력하는 도구가 있습니다. REST 서비스 구현은 수작업으로 수행되며이를 통해 문서를 읽으십시오. 또한이 두 가지 서비스를 구현하는 동안 실제 스키마 나 참조 문서가 없기 때문에 파이프를 통해 무엇이 돌아올 지에 대해 "추측"해야합니다.

2. 어쨌든 XML을 반환하는 REST 서비스를 작성해야하는 이유는 무엇입니까? 유일한 차이점은 REST를 사용하면 각 요소 / 속성이 나타내는 유형을 알지 못한다는 것입니다. 자신의 구현을 통해 언젠가는 항상 int라고 생각한 필드에서 문자열이 나오지 않기를 바랍니다 . SOAP는 WSDL을 사용하여 데이터 구조를 정의하므로 이는 쉬운 일이 아닙니다.

3. SOAP를 사용하면 SOAP Envelope의 "오버 헤드"가 있다는 불만을 들었습니다. 이 시대에 우리는 실제로 몇 바이트에 대해 걱정할 필요가 있습니까?

4. REST를 사용하면 URL을 브라우저에 넣고 데이터를 볼 수 있다는 주장을 들었습니다. REST 서비스가 단순 인증을 사용하거나 인증을 사용하지 않는 경우에는 물론입니다. 예를 들어 Netflix 서비스는 OAuth를 사용하므로 요청을 제출하기 전에 서명하고 인코딩해야합니다.

5. 각 리소스에 대해 "읽을 수있는"URL이 필요한 이유는 무엇입니까? 서비스를 구현하기 위해 도구를 사용하는 경우 실제 URL에 관심이 있습니까?

탄광에서 카나리아.

나는 이런 질문을 1 년 가까이 기다리고있었습니다. 오늘이 올 것이 불가피했고 앞으로 몇 달 안에 더 많은 질문을 보게 될 것입니다.

경고 표시

SOAP 클라이언트보다 RESTful 클라이언트를 빌드하는 데 시간이 오래 걸립니다. SOAP 툴킷은 많은 상용구 코드를 제거하고 거의 노력없이 클라이언트 프록시 객체를 사용할 수있게합니다. Visual Studio와 같은 도구 및 서버 URL을 사용하면 5 분 이내에 로컬로 임의의 복잡한 원격 개체에 액세스 할 수 있습니다.

application / xml 및 application / json을 반환하는 서비스는 클라이언트 개발자에게 성가시다. 우리는 그 데이터를 어떻게 처리해야합니까?

다행히도 REST 서비스를 제공하는 많은 사이트는 많은 클라이언트 라이브러리를 제공하므로 이러한 라이브러리를 사용하여 강력한 형식의 개체에 액세스 할 수 있습니다. 그래도 바보 같은 것 같습니다. 그들이 SOAP를 사용했다면 우리는 그 프록시 클래스를 직접 코드 생성 할 수있을 것이다.

SOAP 오버 헤드, ha. 대기 시간이 줄어 듭니다. 사람들이 실제로 초과 바이트 수를 걱정하고 있다면 HTTP가 올바른 선택이 아닐 수도 있습니다. 사용자 에이전트 헤더가 몇 바이트를 사용하는지 보셨습니까?

예, HTML 및 자바 스크립트 이외의 다른 디버깅 도구로 웹 브라우저를 사용해 보셨습니까? 짜증나게 해줘 동사 중 두 개만 사용할 수 있으며 캐싱은 끊임없이 방해를받으며 오류 처리는 많은 정보를 삼키며 끊임없이 favicon.ico를 찾고 있습니다. 날 쏴

읽을 수있는 URL. 명사 만, 동사는 없어요 예, CRUD 작업 만 수행하는 한 간단하고 한 가지 방식으로 개체 계층 구조에만 액세스하면됩니다. 불행히도 대부분의 응용 프로그램은 그보다 약간 더 많은 기능이 필요합니다.

임박한 재앙

현재 동일한 결론을 내리는 REST 서비스와 통합되는 애플리케이션을 개발중인 개발자의 메트릭 보트로드가 있습니다. 그들은 단순성, 융통성, 확장 성, 진 화성 및 평온한 재사용의 성배를 약속 받았다. 웹 자체의 특성은 어떻게 잘못 될 수 있습니까?

그러나 그들은 버저 닝이 큰 문제라는 것을 알고 있지만 컴파일러는 문제를 감지하는 데 도움이되지 않습니다. 수작업으로 작성된 클라이언트 코드는 데이터 구조가 발전하고 URL이 리팩토링됨에 따라 유지 보수가 어렵다. 명사와 4 개의 동사를 중심으로 API를 디자인하는 것은 특히 어려울 수 있습니다. 특히 쿼리 문자열을 사용할 수 있거나 사용할 수없는시기를 알려주는 RESTful Url zealots가 있습니다.

개발자는 왜 Json 형식과 Xml 형식을 모두 지원하기 위해 노력을 낭비하고 있는지 궁금해 할 것입니다. 왜 노력을 하나에 집중하고 잘 수행하지 않습니까?

상황이 어떻게 잘못 되었나요

내가 뭘 잘못했는지 말해 줄게 우리는 개발자로서 마케팅 부서가 우리의 주요 약점을 활용할 수 있도록합니다. 은 총알에 대한 우리의 영원한 수색은 REST가 실제로 무엇인지에 대한 실명을 보여주었습니다. 표면적으로 REST는 너무 쉽고 간단 해 보입니다. Urls로 리소스 이름을 지정하고 GET, PUT, POST 및 DELETE를 사용하십시오. 우리는 이미 그 방법을 알고 있습니다. SELECT, INSERT, UPDATE 및 DELETE가있는 테이블과 열 및 SQL 문이있는 데이터베이스를 수년간 처리 해 왔습니다. 케이크 한 조각이었을 것입니다.

자체 설명 및 하이퍼 미디어 제한과 같은 일부 사람들이 논의하는 REST의 다른 부분이 있지만 이러한 제한은 자원 식별 및 균일 한 인터페이스만큼 단순하지 않습니다. 원하는 목표가 단순 할 경우 복잡성을 더하는 것 같습니다.

이 워터 다운 버전의 REST는 여러 가지 방법으로 개발자 문화에서 검증되었습니다. 리소스 식별과 균일 한 인터페이스를 장려하는 서버 프레임 워크가 만들어졌지만 다른 제약 조건은 지원하지 않았습니다. 접근 방식을 차별화하는 용어가 사용되기 시작했습니다 (HI-REST vs LO-REST, Corporate REST vs Academic REST, REST vs RESTful).

어떤 사람들은 모든 제약 조건을 적용하지 않으면 REST가 아니라고 소리를 지 릅니다. 혜택을받지 못할 것입니다. 반 REST는 없습니다. 그러나 그 목소리는 그들의 소중한 용어가 모호함에서 도난 당하고 주류가되었다는 화가 난 종교적 열성 자로 분류되었습니다. REST 사운드를보다 어렵게 만드는 질투하는 사람들.

REST라는 용어는 분명히 주류가되었습니다. API가있는 거의 모든 주요 웹 속성은 "REST"를 지원합니다. 트위터와 넷플릭스는 매우 유명한 두 가지입니다. 가장 무서운 점은 내가 설명하는 공개 API 하나만 생각할 수 있으며 실제로 하이퍼 미디어 제약 조건을 구현하는 소수가 있다는 것입니다. StackOverflow 및 Gowalla와 같은 일부 사이트는 응답에서 링크를 지원하지만 링크에는 큰 차이가 있습니다. StackOverflow API에는 루트 페이지가 없습니다. 웹 사이트에 대한 홈 페이지가 없다면 웹 사이트가 얼마나 성공적 이었을지 상상해보십시오!

당신은 내가 두려워 두려워

지금까지 작성한 경우 귀하의 질문에 대한 짧은 대답은 API (Netflix 및 Twitter)가 모든 제약 조건을 준수하지 않으므로 REST API가 가져 오는 이점을 얻지 못할 것입니다.

REST 클라이언트는 SOAP 클라이언트보다 빌드하는 데 시간이 오래 걸리지 만 하나의 특정 서비스와 연결되어 있지 않으므로 여러 서비스에서 재사용 할 수 있어야합니다. 웹 브라우저의 고전적인 예를 들어보십시오. 웹 브라우저는 몇 개의 서비스에 액세스 할 수 있습니까? 피드 리더는 어떻습니까? 이제 평균 트위터 클라이언트가 몇 개의 다른 서비스에 액세스 할 수 있습니까? 예, 하나 만요

REST 클라이언트는 단일 서비스와 인터페이스하도록 구축되어서는 안되며 모든 서비스에서 제공 할 수있는 특정 미디어 유형을 처리하도록 구축되어야합니다. 명백한 질문은 application / json 또는 application / xml을 제공하는 서비스를 위해 REST 클라이언트를 어떻게 구축 할 수 있는가입니다. 당신은 할 수 없습니다. 이는 해당 형식이 REST 클라이언트에 완전히 쓸모 없기 때문입니다. 당신이 직접 말 했어요

실제 스키마 나 참조 문서가 없기 때문에 파이프를 가로 질러 다시 돌아 오는 것에 대해 "추측"을해야합니다.

트위터와 같은 서비스에 대해서는 절대적으로 정확합니다. 그러나 REST의 자체 설명 제약 조건에 따르면 HTTP 컨텐츠 유형 헤더는 유선을 통해 전송되는 컨텐츠를 정확하게 설명해야합니다. application / json 및 application / xml을 제공하면 내용에 대해 아무 것도 알려주지 않습니다.

REST 기반 시스템의 성능을 고려할 때 더 큰 그림을 봐야합니다. 엔벨로프 바이트에 대해 말하는 것은 빠른 정렬을 쉘 정렬과 비교할 때 루프 해제를 말하는 것과 같습니다. SOAP이 더 잘 수행 될 수있는 시나리오가 있고 REST가 더 잘 수행 할 수있는 시나리오가 있습니다. 상황이 전부입니다.

REST는 지원하는 미디어 유형에 대해 매우 유연하고 캐싱에 대한 정교한 지원을 통해 많은 성능 이점을 얻습니다. 캐싱이 제대로 작동하려면 거의 모든 제약 조건을 준수해야합니다.

읽을 수있는 URL에 대한 마지막 요점은 훨씬 역설적입니다. 하이퍼 미디어 제약 조건에 충실하면 모든 URL이 GUID가 될 수 있으며 클라이언트 개발자는 가독성을 잃지 않습니다.

URI가 클라이언트에게 불투명해야한다는 사실은 REST 시스템을 개발할 때 가장 중요한 것 중 하나입니다. 읽을 수있는 URL은 서버 개발자에게 편리하고 체계적인 URL로 서버 프레임 워크가 요청을보다 쉽게 ​​전달할 수 있지만 API를 사용하는 개발자에게는 영향을 미치지 않는 구현 세부 사항입니다.

Twitter API는 RESTful에 가깝지 않기 때문에 SOAP보다 API를 사용하는 데 따른 이점을 볼 수 없습니다. Netflix API는 훨씬 더 가깝지만 일반 미디어 유형을 사용하면 단일 제약 조건을 준수하지 않아도 서비스에서 파생 된 이점에 큰 영향을 줄 수 있음을 알 수 있습니다.

전부 잘못이 아닐 수도 있습니다

나는 서비스 제공 업체에 많은 덤핑을 해왔지만 RESTfully 춤을 추려면 두 가지가 필요합니다. 서비스는 종교적으로 모든 제약을 따를 수 있으며 고객은 여전히 ​​모든 혜택을 쉽게 취소 할 수 있습니다.

클라이언트가 특정 유형의 리소스에 액세스하기 위해 URL을 하드 코딩하면 서버가 해당 URL을 변경하지 못하게됩니다. 서비스가 URL을 구성하는 방법에 대한 암시 적 지식을 기반으로하는 모든 종류의 URL 구성은 위반입니다.

링크에서 어떤 유형의 표현이 반환되는지에 대한 가정을하면 문제가 발생할 수 있습니다. HTTP 헤더에 명시 적으로 명시되지 않은 지식을 기반으로 표현의 내용에 대한 가정을하는 것은 미래에 고통을 야기 할 수있는 결합을 확실히 만들 것입니다.

그들은 SOAP을 사용해야 했습니까?

개인적으로는 그렇게 생각하지 않습니다. REST가 올바르게 수행되면 분산 시스템이 장기적으로 발전 할 수 있습니다. 다른 사람들이 개발 한 구성 요소가 있고 수년간 지속해야하는 분산 시스템을 구축하는 경우 REST는 매우 좋은 옵션입니다.

SOAP는 것입니다 객체 지향 , 원격 프로 시저 호출 기술 스택. 기존 프로토콜 (HTTP) 위에 새로운 추상화를 구축하여 작동합니다.

REST는 기존 프로토콜 (HTTP)의 기능을 사용 하는 문서 지향 접근 방식입니다. "REST"다만 화두이다 - 개념은 이것이다 : 그냥 웹에게이 된 방법으로 사용하는 설계 작업에를!

질문 수정 사항에 대한 답변 :

1. "RESM 서비스를 구현하는 데 SOAP 서비스를 구현하는 것보다 시간이 오래 걸립니다."

   음, 아니, 그것은 될 수 없습니다 무한히 이상. 그리고 당신이 검색하려고하는 것이 이미 문서 또는 파일 인 경우에는 실제로 훨씬 빠릅니다 . 예를 들어 WMS (Web Mapping Service)에 대한 OGC 사양은 프로토콜의 SOAP 및 REST 버전을 모두 정의하며, SOAP 버전을 구현하는 사람이 거의없는 이유가 있습니다.지도를 가져 오려고하면 SOAP 메시지로 캡슐화하는 것보다 URL을 빌드하고 해당 URL에서 이미지 바이트를 가져 오는 것이 훨씬 쉽습니다. 그러나 웹 서비스의 요점이 도메인 개체 모델에서 강력한 형식의 개체를 전송하는 경우 SOAP가 해당 용도에 더 적합하다는 데 동의합니다.

2. "어쨌든 XML을 반환하는 REST 서비스를 작성하는 이유는 무엇입니까?"

   글쎄, 그건 바보 같아 그러나 XML이 무엇인지에 달려 있습니다. 어딘가에 스키마가 명확하게 정의되어 있으면 모호성이 없습니다. 예를 들어 WSDL URL을 웹 서비스에 대한 정보를 검색하기위한 일종의 RESTful 웹 서비스라고 생각할 수 있습니다. 이 경우 다른 SOAP 요청의 오버 헤드를 추가하는 것은 의미가 없습니다.

   일반적으로 REST는 전송중인 컨텐츠를 단일 단위로 파일 로 생각할 수있을 때 승리합니다 . 내용 이 구성원이 있는 객체 로 취급되어야 할 때 SOAP가 승리합니다 .

3. "SOAP를 사용하면 SOAP Envelope의"오버 헤드 "가 있다는 불만을 들었습니다.이 시대에 우리는 실제로 몇 바이트를 걱정해야합니까?"

   예. 모든 상황에 해당되는 것은 아니지만 트래픽을 많이 발생시키는 사이트가 있습니다. REST 대신 SOAP를 사용 하는 것의 의미 상의 차이점을 능가하는 데 충분한 차이가 있습니까? 나는 그것을 의심한다. 객체 원격 프로토콜을 수행하고 바이트 수가 차이가 나는 경우 SOAP는 아마도 당신을위한 도구가 아닐 수도 있습니다. 아마도 CORBA 또는 DCOM을 사용해야합니다.

4. "REST를 사용하면 URL을 브라우저에 넣고 데이터를 볼 수 있다는 주장을 들었습니다."

   예 . 브라우저에서 데이터를 보는 것이 합리적이라면 REST를 선호하는 큰 주장입니다 . 예를 들어 이미지 데이터를 사용하면 서비스를 쉽게 디버깅 할 수 있습니다. URL을 브라우저의 주소 표시 줄에 붙여 넣고 이미지의 모양을 확인하십시오. 또는 반환 된 데이터가 XML로되어 있고 브라우저에서 읽을 수있는 HTML로 렌더링되는 참조 된 XML 스타일 시트가있는 경우 시맨틱 마크 업의 이점과 하나의 패키지로 쉽게 시각화 할 수 있습니다. 그러나보다 복잡한 인증 체계로 작업 할 때는 이러한 이점이 대부분 사라집니다. 모든 인증 정보를 각 HTTP 요청으로 인코딩 할 수 없다면 REST로 간주되지 않는다고 주장합니다.

5. "각 리소스마다"읽을 수있는 "URL이 필요한 이유는 무엇입니까? 서비스를 구현하기 위해 도구를 사용하는 경우 실제 URL에 관심이 있습니까?"

   글쎄요. 웹상의 리소스에 대해 읽을 수있는 URL이 필요한 이유는 무엇입니까? Tim Berners-Lee의 에세이를 읽을 수 있습니다. Cool URIs 는 이론적 근거로 변경되지 않지만 기본적으로 향후 리소스가 여전히 유용 할 수있는 한 해당 리소스의 URI는 동일하게 유지되어야합니다.

   분명히, 에세이의 "오늘의 돈"링크와 같은 일시적인 자원의 경우, 해당 자원이 없어지면 자원을 참조 할 필요가 없어 지므로 필요하지 않습니다. 그러나보다 영구적 인 리소스 (예 : StackOverflow 질문 또는 IMDB의 영화)의 경우 영원히 작동하는 URL을 원합니다. 웹 서비스를 디자인 할 때는 리소스 자체가 서비스보다 오래 지속될 수 있는지 결정해야하며, 그렇다면 REST가 올바른 방법 일 것입니다.

네, NetFlix 나 Twitter가 존재하기 훨씬 전에 웹 페이지를 개발하고 있습니다. 그리고 아직 NetFlix 또는 Twitter 서비스에 클라이언트를 구현할 필요가 없습니다. 그러나 서비스가 엄청나게 다루기가 어려워도 서비스를 구현 한 기술이 나쁘다는 의미는 아닙니다. 단지 두 가지 구현이 나쁘다는 것입니다.

간단히 말해 REST와 SOAP는 도구 일뿐 입니다. 그들은 각각 장단점이 있습니다. 당신이 가진 유일한 도구가 망치라면, 모든 문제는 못처럼 보입니다. 따라서 두 도구를 모두 알고 올바르게 사용하는 방법을 배우고 각 작업에 적합한 도구를 선택하십시오.

정직한 질문은 정직한 답변이 필요합니다. 그러나 첫째, 왜이 질문의 본문 이 수사적이라고 생각하지 않는다면 다른 질문에 대한 답으로 사용 했습니까?

어쨌든:

1. " 모든 현대 언어 / 프레임 워크 / 플랫폼이 WSDL에서 읽고 프록시 클래스와 클라이언트를 출력 할 수있는 도구가 존재합니다. REST 서비스 구현은 문서를 읽어서 직접 수행합니다. "

   브라우저 공급 업체가 일관된 브라우징 환경을 구현하기 위해 HTML 4.01 사양을 읽고 다시 읽은 것처럼. 인터넷 뱅킹 및 스택 오버플로 이전에 브라우저가 발명되었다는 사실을 생각해 보았지만 브라우저를 사용하여 이러한 작업을 수행 할 수 있습니다. 모든 사람들이 HTML (및 CSS, JS, JPEG 등의 관련 형식)을 사용하기로 동의 한 유일한 이유 때문에 가능합니다.

   블로깅은 실제로 새로운 것이 아니며, 누군가 웹 브라우저가 웹 페이지에 액세스 할 수있는 것처럼 블로그 소프트웨어가 블로그의 게시물에 액세스하고 업데이트 할 수 있도록하는 AtomPub를 개발했습니다. 그것은 매우 깔끔하고 프로토콜에 의해 부과되는 RESTful 제약 때문에 작동합니다.

   그러나 Twitter와 Netflix의 경우, "기존의 모든 마이크로 블로그가 미디어 유형 응용 프로그램 / 트위트를 사용해야한다"는 보편적 인 합의는 없습니다. 주로 마이크로 블로깅이 매우 새롭기 때문입니다. 몇 년 후 몇 개의 마이크로 블로그 서비스가 동일한 API에 정착하여 Twitter, Facebook, Identica 및 상호 운용 될 수 있습니다. 기존 API 중 어느 것도 RESTful 근처에 있지 않지만 많은 주장이 있기 때문에 곧 일어날 것이라고는 생각하지 않습니다.

   " 또한이 두 서비스를 구현하는 동안 실제 스키마 나 참조 문서가 없기 때문에 파이프를 통해 무엇이 다시 올지에 대해"추측 "을해야합니다. "

   머리에 못을 박았다. REST는 분산 및 하이퍼 미디어에 관한 것입니다. 브라우저는 요청에서 얻은 내용을보고 사용자에게 보여줍니다. HTML 페이지는 일반적으로 CSS, 스크립트 및 이미지와 같은 더 많은 GET 요청을 생성합니다. 이미지는 일반적으로 화면에만 렌더링되고 JavaScript는 실행됩니다. 매번 브라우저는 <img>또는 <style>태그 에서 링크를 찾았고 응답 미디어 유형이 image/jpeg또는 이므로 브라우저가 수행하는 작업을 수행합니다 text/css.

   트위터가 하이퍼 미디어 기반 API를 만드는 경우 application/tweet, 트윗 링크를 따라갈 때마다 항상 반환 될 것이지만, 클라이언트는 절대 그것을 가정하지 말고 행동을 취하기 전에 항상 그 내용을 확인해야합니다.

2. " 어쨌든 XML을 반환하는 REST 서비스를 작성해야하는 이유는 무엇입니까? "

   이것은 모두 미디어 유형으로 요약됩니다. HTML과 마찬가지로 실제로 의미가 무엇인지 모르는 요소가 표시되면 HTML 사양에서 해당 요소를 무시하고 태그의 "본체"(있는 경우)를 처리하도록 지시합니다. 마찬가지로 atom 스펙은 알려지지 않은 요소 및 외부 마크 업 (다른 네임 스페이스의)을 무시 하고 본문 (IIRC)을 처리 하지 않도록 지시합니다 .

   리치 텍스트 문제점 도메인 의 HTML 매체 유형 에서와 같이 일반적인 문제점 도메인의 매체 유형을 설계하는 것은 매우 어렵습니다. 매우 좁은 문제 도메인에 대한 미디어 유형을 만드는 것이 아마도 트윗처럼 훨씬 쉬울 것입니다. 그러나 항상 확장 성을 위해 디자인하고 클라이언트와 서버가 사양과 일치하지 않는 요소 나 데이터 항목을 볼 때 반응하는 방식을 지정하는 것이 좋습니다. 예를 들어 JPEG에는 모든 종류의 메타 데이터를 포함하는 데 사용되는 응용 프로그램 별 레코드 유형 (예 : APP1)이 있습니다.

3. " SOAP를 사용하면 SOAP Envelope의"오버 헤드 "가 있다는 불만을 들었습니다.이 시대에는 몇 바이트에 대해 정말로 걱정해야합니까? "

   아닙니다. REST는, 실제로에서 와이어 효율을 거래 있어요 와이어를 통해 효율적인 것에 대해 절대적으로하지 않습니다 REST의 효율 캐싱의 다른 모든 제약으로 활성화 가능성에서 온다 :. 필딩의 논문 사항 : 절충는하지만, 그 균일 한 인터페이스 저하입니다 정보는 응용 프로그램의 요구에 맞는 형식이 아닌 표준화 된 형식으로 전송되기 때문에 효율성이 높습니다. REST 인터페이스는 대규모의 하이퍼 미디어 데이터 전송에 효율적으로 설계되어 웹의 일반적인 경우를 최적화하지만 다른 형태의 아키텍처 상호 작용에는 최적의 인터페이스가되지 않습니다. SOAP Envelope 바이트 수 오버 헤드가 유효한 문제라고 생각하지 않습니다.

4. " REST를 사용하면 URL을 브라우저에 넣고 데이터를 볼 수 있다는 주장을 들었습니다. "

   예, 그것은 또한 잘못된 주장입니다. 그런 식으로 작동하지 않습니다. 그것이 작동하더라도, 가장 좁은 REST API는 브라우저가 알지 못하고 여전히 작동하지 않는 미디어 유형을 사용합니다.

   그러나 HTTP 요청의 거의 모든 측면을 제어하고 응답 헤더를 검사하며 따라갈 수있는 링크를 찾을 수있는 명령 줄 유틸리티 또는 브라우저 확장과 같은 HTTP 기반 API를 테스트 할 수있는 가능성이 브라우저보다 훨씬 많습니다. 그러나 그럼에도 불구하고 WSDL 스텁을 생성하고 함수를 호출하는 3 줄 프로그램을 만드는 것만 큼 쉬운 방법은 없습니다.

5. " 각 리소스에"읽을 수있는 "URL이 필요한 이유는 무엇입니까? 서비스를 구현하기 위해 도구를 사용하는 경우 실제 URL에 관심이 있습니까? "

   웹의 작동 방식을 살펴보면 wikipedia 페이지의 URI가 http://en.wikipedia.org/wiki/Stack_overflow대신에 다음과 같이 표시되어 있기 때문에 많은 사람들이 기뻐할 것입니다 http://en.wikipedia.org/wiki/?oldid=376349090. 그러나 실제로 REST하는 것은 중요하지 않습니다. 올바른 정보를 얻으려면 중요한 것은 변경되지 않는 관련 데이터를 URI에 배치하는 것입니다. 데이터베이스 ID는 절대 변경되지 않는다고 생각할 수 있지만 두 데이터 세트를 병합해야 할 경우 어떻게됩니까? 모든 기본 키가 변경됩니다. 페이지 제목 (Stack_overflow)은 변경되지 않습니다.

긴 답변에 대해 죄송하지만이 질문은 유효하며 여기에서는 아직 해결되지 않았습니다. Darrel Miller가 다시 돌아 오면 답변을 추가 할 것이라고 확신합니다.

편집 : 서식

Martin Fowler는 Richardson Maturity Model에 대한 게시물을 가지고 있는데 SOAP과 REST의 차이점을 잘 설명하고 있습니다.

WSDL 및 기타 문서 레벨 프로토콜은 중복됩니다. HTTP 프로토콜은 문서를 제공하고 양식을 제출하는 것 외에도 훨씬 다양한 작업을 지원합니다.

REST의 지지자들은 그 중복성에 불편하다.