Web Api에 대한 WSDL 유형 지원이없는 이유는 무엇입니까?

.Net WebApi로 시작하고 바로 눈에 띄는 것은 API의 모양과 소비 방식을 정의하는 계약이 없다는 것입니다 (각 작업의 요청 / 응답). WCF / Soap 용 WSDL

이것은 매우 귀중한 것이며 API 소비자가 인생을 훨씬 쉽게 만들 수있는 것 같습니다.

없는 이유가 있습니까? 내가 모르는 프로그래밍 패러다임이나 원칙이 있습니까? 내가 만들 수있는 방법이 있습니까?

비누, 휴식 및 사람들의 창의력

SOAP는 WSDL과 같은 설명 문서가 필요합니다. 각 자원은 다른 메시지로 소비 될 수 있기 때문에, 자원을 조작 할 수있는 가능한 이름 / 메시지에 대한 제한 조건에 대한 프로토콜 정의는 없습니다.

예를 들어, SOAP에서 클라이언트가 사용자를 조작 할 수있게하는 웹 서비스는 다음과 같은 다양한 메시지로 사용자를 작성하는 조작을 노출 할 수 있습니다.

addUser
createUser
insertUser

물론 많은 재미있는 웹 서비스 메소드 이름을 보았으므로 샘플 메시지는 거의 없습니다. 거기에는 정말 창의적인 사람들이 있습니다.

반면에 REST 원칙을 실제로 준수하는 웹 API를 사용하여 기본 시스템을 노출하는 경우 클라이언트는 사용자라는 자원이 있음을 알아야합니다. 방법

POST /Users

그리고 이것은 SOAP 또는 웹 API REST를 사용하여 노출하려는 각 작업에 대해 발생합니다.

SOAP 프로토콜 임에도 불구하고, 할 수 있거나 할 수없는 것을 제한하고 스타일 아키텍처 REST가되어 작업 방법에 대한 많은 열린 지점을 남깁니다. REST 웹 API를 노출하고 사용하는 방법에 대한 규칙을 정의하려는 노력이 있습니다.

웹 API REST 설명

웹 API REST를 설명하는 방법 분야에서 Swagger 를 인용 할 수 있습니다 . 웹 API REST와 유사한 WSDL을 작성하려는 시도는 아니지만 웹 API REST를 설명하기위한 공개 표준을 작성하는 것이 좋습니다.

Swagger는 RESTful 웹 서비스를 설명, 생성, 소비 및 시각화하기위한 사양 및 완벽한 프레임 워크 구현입니다.

Swagger UI 를 사용하면 웹 API에 대한 멋진 라이브 콘솔과 문서를 생성 할 수있는 Swagger UI 가 주로 사용됩니다.

C #, Java, Python, Ruby 등 대부분의 언어에 대해 많은 Swagger 구현이 있습니다.

ASP .NET Web API를 사용하는 경우 Swagger.NET 과 같은 Swagger 스펙을 자동 생성하는 프로젝트가 있습니다.

웹 API REST에 클라이언트 생성

제한된 동사 집합 (GET, POST, PUT, DELETE 등)과 같은 REST 제약 조건이 클라이언트 API를 웹 API REST에 생성하기에는 그리 어렵지 않기 때문입니다.

WebApiProxy 와 같은 프로젝트 는 클라이언트가 C # 및 Javascript를 쉽게 생성 할 수 있습니다.

웹 API REST를위한 컨벤션

웹 API REST의 작동 방식에 대한 몇 가지 규칙을 정의하여 개발자의 편의성을 높이기 위해이 분야에서 내가 아는 최선의 노력은 매우 훌륭한 Apigee-Web Api Design ebook 입니다. 전자 책은 API를 디자인하는 방법에 대한 성경이나 진언을 만들려는 시도가 아니라 Twitter, Facebook, Linkedin, Google 등과 같은 대형 웹 REST API에서 관찰되는 규칙 모음입니다.

간단히 말해서, SOAP는 자체 설명이 가능하도록 설계 되었기 때문에 : SOAP 종점에는 일반적으로 제공되는 작업과 각 작업이 수행 및 / 또는 반환하는 데이터 (내장 XSD를 통해)가 어떻게 보이는지 설명하는 wsdl이 포함됩니다.
이 자체 설명으로 인해 Visual Studio와 같은 응용 프로그램에서 웹 서비스 프록시를 생성 할 수 있습니다.

또한 SOAP에 대한 암호화 또는 트랜잭션 동작을 사용할 수 있도록 SOAP에 대한 몇 가지 확장 (WS- * 사양)이 있습니다. 아이디어는 엔터프라이즈 급 웹 서비스를 작성하는 원 스톱 상점으로 SOAP를 사용할 수 있다는 것입니다.

반면에 ...

WebAPI는 REST 서비스를 제공하도록 설계되었습니다. REST의 통신 형식은 일반적으로 JSON 또는 일반 XML입니다. 실제로 중요하지는 않지만 일반 텍스트 일 ​​수도 있습니다. REST 서비스는 완전히 다른 철학을 따릅니다. AJAX 솔루션의 일부로 클라이언트 쪽 스크립트 나 모바일 장치에서 쉽게 사용할 수 있도록 경량입니다.
따라서 자기 설명을 포함하여 의식 수준을 최소한으로 유지할 필요가 있습니다. 또한 원하는 경우에도 REST 서비스 (예 : JSON)에 사용되는 대부분의 통신 형식에는 내용을 설명하는 공식적인 방법이 없습니다.

요약하자면, SOAP 웹 서비스는 일반적으로 솔루션을 통합하는 데 사용되며 (별도의), REST 서비스는 동일한 솔루션의 일부간에 통신을 제공하는 데 더 적합합니다.

SOAP / WS- *와 RESTful API는 동일하지 않습니다. SOAP / WS- * WSDL 지원 API를 빌드하려는 경우 Microsoft 스택에서 선택하는 도구는 WCF이며 HTTP 바인딩 옵션 (XML 및 JSON 바인딩 옵션, XML은 WSDL 지원 옵션)으로 마운트됩니다.

실제로 다른 구현 언어 또는 플랫폼에서 WSDL을 사용하는 것은 문제가되었습니다. WS- * 보안 계층은 최상위에 있습니다.

내 경험은 주로 이와 관련하여 .Net, Node, Java 및 PHP에 대한 경험이었으며 하위 유형의 세부 정보를 정의 할 필요가없는 플랫폼이 있거나 "Object"를 정의가 가장 적다는 것은 문제가된다. 이 외에도, 대부분의 SOAP / WS- *가 툴링에 크게 의존하여 모든 툴을 제대로 이해하는 사람은 아무도 없습니다. 이 툴링에는 많은 오버 헤드가 있으며 시스템마다 다르게 작동합니다.

이것이 사람들이 더 간단한 구현을 시도하는 이유 중 일부입니다. REST 서비스 (ala Web API)는 객체 / 상태에 대한 엔드 포인트를 제공합니다. JSON 형식으로 표현되는 간단한 객체 구조 세트를 정의하는 것이 더 쉽다는 개념과 작동하지 않는 외부 환경에서 WSDL을 사용하려고 시도하는 것보다 이러한 구조에 대해 엔드 포인트를 사용하는 것이 더 쉽습니다. 문제를 해결하십시오.

아이러니하게도, 이것은 번역 서비스로 노드를 많이 사용하는 영역 중 하나입니다. 단순히 클라이언트로서 더티 구현을 수용 할 수있을만큼 유연했기 때문입니다. 더 잘 작동하는 적응 된 페이로드에 대해 간단한 클라이언트를 작성할 수 있습니다. 예 : C #은 JSON.Net을 사용하여 JSON.Net을 사용하여 WSDL 가져 오기를 사용할 수 없을 때 실제로 정의한 객체 표현으로 변환합니다.

실제로 이것은 많은 일이 발생합니다.

여기에 많은 대답이 훌륭하지만 대답이 훨씬 간단하다고 생각합니다. 잘못된 기술을보고 있습니다.

SOAP 서비스를 구축하려면 WCF를 고수해야합니다. 그것은 여전히 ​​매우 강력한 프레임 워크이며, Microsoft는 여전히 적극적으로 개발하고 있으며, 앞으로 어디로 갈지에 대한 발표는 없었으며,이를 염두에두고 만들어졌습니다. 웹 API는 WCF를 대체하지 않습니다 (WCF보다 최신 버전 일 수도 있음).

웹 API는 WCF의 일부 였지만 다른 WCF 기술과 함께 사용할 수 없기 때문에 ASP.NET 제품군으로 옮겨졌습니다. 웹 API는 전송 프로토콜보다 HTTP를 애플리케이션 프로토콜로 사용하는 데 훨씬 더 관심이 있습니다. Web API에서 HTTP 동사는 왕이며 WCF에서 HTTP는 단지 SOAP 프로토콜을 활성화하는 역할을합니다.

의도하지 않은 특정 작업을 수행 할 수있는 기능을 제공하지 않았다고 웹 API를 비난하지 마십시오.