튜토리얼 <web-service-php-mysql-xml-json>을 읽었습니다.
모든 것이 괜찮은 것 같습니다. 그렇다면 왜 웹 서비스에 비누를 사용해야 할까요?
웹 서비스를 구축할 때는 두 가지 방법을 사용할 수 있습니다:
대부분의 사람들은 저항이 적은 경로, 즉 REST를 선택합니다. 이는 단순성, 개발 용이성, HTTP의 원래 사용 방식대로 사용, 캐시 프록시 활용, 사람이 더 읽기 쉬운 결과 등을 의미합니다.
반면에 SOAP는 REST보다 더 무겁고 많은 사양으로 뒷받침됩니다. 그러나 더 복잡하기 때문에(SOAP는 예전에는 단순한 객체 액세스 프로토콜의 약어였습니다. 아닌 것으로 판명됨) SOAP는 많은 사람들이 좋아하지 않습니다.
**두 접근 방식 모두 효과가 있으며 장단점이 있습니다.
예를 들어, SOAP는 HTTP(S) 뿐만 아니라 모든 전송 프로토콜을 사용할 수 있고, 보안과 관련하여 더 많은 옵션을 제공하며, 안정적인 메시징 등을 제공합니다. 반면에 REST는 다양한 유형의 데이터 형식을 허용하고, JSON 형식으로 인해 브라우저를 더 잘 지원하며, REST의 성능이 더 우수하다는 등의 장점이 있습니다.
웹에서 SOAP과 REST를 비교하는 많은 자료를 찾을 수 있으므로 더 자세히 설명하지 않겠습니다. 제가 강조하고 싶은 것은 어떤 경우에는 한 쪽이 다른 쪽보다 더 잘 작동하며 특정 사례를 고려하여 어떤 것을 구현할지 결정하고 선택하는 것은 사용자의 몫이라는 사실입니다.
편집: 질문에 답하자면: <왜 SOAP이나 REST를 사용해야 하나요? 그것들 없이도 웹 서비스를 제공할 수 있는데?
W3C는 웹 서비스를 <네트워크를 통해 상호 운용 가능한 기계 간 상호 작용을 지원하도록 설계된 소프트웨어 시스템>으로 정의합니다.
좋아요... 좋은 정의입니다. 그러나 이것은 SOAP/REST에 대한 정의가 아니며, 이 요구 사항은 통신 프로토콜에서 성공적으로 처리할 수 있습니다.
따라서 기본적으로 '상호 운용 가능한 기계 간 상호 작용'을 지원하는 한 원하는 통신 프로토콜을 사용하는 웹 서비스를 만들 수 있습니다(자체 프로토콜을 만들 수도 있음). 이는 SOAP이나 REST가 아닌 다른 것을 의미하기도 합니다(알겠습니다... REST는 프로토콜이 아니라 제 요점을 증명하기 위해 참고용으로 사용한 것입니다... 조금만 참아주세요).
하지만 여러분이 웹 서비스를 만드는 이유는 일부 클라이언트가 여러분의 서비스를 사용하기를 원하기 때문입니다. 그리고 당신의 클라이언트는 야생의 서부(즉, 웹)에 있고 그곳의 사람들은 SOAP/REST를 사용합니다. 거기서 여러분은 이렇게 말하겠죠: "*우리는 우리 가게에서 SOAP과 REST를 좋아하지 않고, RPC, CORBA, 그리고 우리만의 고유한 프로토콜인 <본 크러셔 10000>을 좋아합니다.". 저희와 거래하고 싶으시다면 '본 크러셔 10000'을 배우러 가세요. 그러면 고객들은 (눈썹을 치켜들고) "아, 맞다!"라고 말할 것입니다.
*(여기서 여러분의 프로토콜이 SOAP/REST를 완전히 능가하는 지저분한 것이 아니라고 가정하고 있습니다 :D).
따라서 SOAP/REST를 사용하지 않는다면 타겟 고객을 제한하게 될 것입니다. 예를 들어 영어와 같습니다. 저는 영어가 모국어가 아닌데, 그렇죠? 영어로 의사소통이 가능하기 때문에 크게 중요하지 않습니다. 아이슬란드어]4로 해볼까요? . 아이슬란드어도 제 모국어가 아니니 아이슬란드어를 배울 때까지 기다려 주시겠어요?
이미 말씀드렸듯이 특정 사례에 따라 무엇을 구현할지 결정하고 선택하는 것은 여러분의 몫이지만, 알려진 기술 스택에서 벗어나면 그에 수반되는 모든 것을 버리는 것입니다: 많은 경험, 리소스, 도구 및 커뮤니케이션 옵션을 버리게 됩니다.
마지막으로, 오늘날에는 SOAP 프로토콜에 대한 지원이 많이 이루어지고 있으며 WSDL 파일에서 시작하여 매우 쉽게 클라이언트를 생성할 수 있습니다. 그리고 프레스토... 클라이언트가 웹 서비스와 통신할 수 있습니다. 본 크러셔 10000을 사용하면 이렇게 쉽게 할 수 있을까요? 도구를 작성하고, 리소스, 지원 등을 제공하면...? 네! 하지만 그렇게 하려면 이미 발명되어 오늘날 널리 사용되고 있는 무언가를 만드는 데 시간과 비용이 들게 됩니다.
사용자 159088이 답변에서 언급 한 중요한 점은 [...][...] WSDL 파일에서 시작하여 매우 쉽게 클라이언트를 생성 할 수 있다는 것입니다 [...] &"!
이에 대해 더 자세히 설명하고 싶습니다:
표준화되어 있기 때문에 표준(WSDL)을 아는 사람은 웹서비스가 어떤 작업을 제공하고 데이터가 어떻게 교환되는지 알 수 있다는 의미로 표준화된 WSDL과 함께 SOAP을 사용할 수 있습니다.
이러한 지식은 예를 들어 WSDL 파일에서 유형 안전 바인더 클래스/객체를 생성하는 도구를 만드는 데 사용할 수 있습니다. 교환되는 데이터의 요청과 인코딩/파싱을 수동으로 구현하지 않고도 생성된 클래스를 사용하여 (RPC를 만드는 데) 사용할 수 있습니다.
반면, REST의 경우 교환되는 데이터의 모양에 대한 표준(예: WSDL 스키마)이 없습니다. 따라서 데이터를 직접 파싱해야 하는 경우가 많습니다.
두 번째 요점은 REST가 주로 HTTP(s) 프로토콜에서 작동한다는 점입니다(이를 기반으로 합니다). HTTP(s) 프로토콜의 CRUD 동사(CREATE/READ/UPDATE/DELETE)를 사용합니다. SOAP는 이 프로토콜에 의존하지 않으므로 다른 프로토콜과도 함께 사용할 수 있습니다.