RESTful 서비스-동등한 WSDL

저는 REST와 SOAP에 대해 읽었으며 REST를 구현하는 것이 SOAP 프로토콜을 사용하는 것보다 유익 할 수있는 이유를 이해했습니다. 그러나 나는 아직도 REST 세계에 "WSDL"과 동등한 것이없는 이유를 이해하지 못한다. WSDL이 "필요하지 않다"거나 REST 세계에서 중복 될 것이라는 게시물을 보았지만 그 이유를 이해할 수 없습니다. 프로그래밍 방식으로 정의에 바인딩하고 수동으로 코딩하는 대신 프록시 클래스를 만드는 것이 항상 유용하지 않습니까? 나는 철학적 인 논쟁에 참여하려는 것이 아니라 REST에 WSDL이없는 이유 또는 필요하지 않은 이유를 찾는 것뿐입니다. 감사.

웹 응용 프로그램 설명 언어 (WADL)는 기본적으로 편안하고 서비스에 대한 WSDL에 동등하지만 이런 일이 전혀 필요 여부를 지속적으로 논란이있었습니다.

Joe Gregorio는 읽을만한 가치가있는 주제에 대한 멋진 기사 를 작성 했습니다 .

WSDL은 서비스 엔드 포인트를 설명합니다. REST 클라이언트는 서버 엔드 포인트에 연결되어서는 안됩니다 (즉, URL에서 미리 인식하지 않아야 함). REST 클라이언트는 클라이언트와 서버간에 전송되는 미디어 유형에 결합됩니다.

반환 된 미디어 유형을 래핑하기 위해 클라이언트에서 클래스를 자동으로 생성하는 것이 좋습니다. 그러나 서비스 상호 작용을 중심으로 프록시 클래스를 만들기 시작하자마자 HTTP 상호 작용을 가리기 시작하고 RPC 모델로 되돌아 갈 위험이 있습니다.

RSDL은 하이퍼 미디어처럼 휴식을 취하는 것을 목표로합니다. 즉, WSDL 또는 WADL과 같은 서비스 설명자보다 더 많은 정보를 가지고 있습니다. 예를 들어 하이퍼 텍스트 및 하이퍼 링크와 같은 탐색에 대한 정보가 있습니다.

예를 들어 현재 리소스가 주어지면 관련된 다른 리소스에 대한 설정된 os 링크가 있습니다.

그러나이 형식을 지원하는 Rest Clients 또는 자동 생성 기능이있는 Rest Server Solutions를 찾지 못했습니다.

결론에는 먼 길이 있다고 생각합니다. HTML 긴 이야기와 W3C vs Browsers lol을 참조하십시오.

Rest like Hypermedia에 대한 자세한 내용은 http://en.wikipedia.org/wiki/HATEOAS 를 참조하십시오 .

참고 : Roy Fielding은 hypermidia 접근 방식이없는 Rest Apis에서 이러한 경향을 비판했습니다. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

내 결론 : 이제 하루에 WADL은 Camel CXF와 같은 Rest 및 Integration Framework가 이미 WADL (생성 및 소비)을 지원하는 것보다 더 일반적입니다. 이는 WSDL과 유사하므로이 마이그레이션 프로세스 (SOAP에서 REST로)에서 가장 이해하기 쉽습니다.

다음 장을 보자;)

프로그래밍 방식으로 정의에 바인딩하고 수동으로 코딩하는 대신 프록시 클래스를 만드는 것이 항상 유용하지 않습니까?

전심으로 동의합니다. 이것이 제가 Swagger.io를 사용하는 이유입니다.

Swagger는 RESTful API를 설계, 빌드, 문서화 및 사용하는 데 도움이되는 대규모 도구 에코 시스템이 지원하는 강력한 오픈 소스 프레임 워크입니다.

그래서 기본적으로 Swagger를 사용하여 모델, 엔드 포인트 등을 설명한 다음 swagger-codegen 과 같은 다른 도구를 사용하여 수동으로 코딩하는 대신 프록시 클래스를 생성합니다.

참조 : RAML

WSDL에 해당하는 RSDL (restful service description language)이 있습니다. 아래 URL은 http://en.wikipedia.org/wiki/HATEOAS 및 http://en.wikipedia.org/wiki/RSDL 관행을 설명합니다 . 문제는 wsdl에서 java로 또는 그 반대로 코드를 생성하는 도구가 많다는 것입니다. 하지만 RSDL에서 코드를 생성하는 도구를 찾지 못했습니다.

WSDL은 통신에 사용되는 메시지 형식 또는 네트워크 프로토콜에 관계없이 끝점 및 해당 메시지에 대한 설명을 허용하도록 확장 가능합니다.

그러나 REST는 HTTP 동사와 URI를 사용하여 네트워크 프로토콜을 사용하여 개체 상태를 나타냅니다.

WSDL은이 위치에서이 메시지를 보내면이 작업을 수행하고 결과적으로이 형식을 다시 가져올 것이라고 말합니다.

REST에서 새 프로필을 만들고 싶다면 POSTURL에 대한 프로필을 설명하는 JSON 본문 또는 http 서버 변수와 함께 동사 를 사용합니다./profile

POST상태 코드 201 CREATED와 헤더 Location: *new_profile_id*(예 : 12345)를 사용하여 서버 측에서 생성 된 ID를 반환해야합니다.

그런 다음 /profile/12345HTTP 동사 사용 상태를 변경하는 업데이트를 수행 할 수 POST있습니다 (예 : 내 이메일 주소 또는 전화 번호 변경). 분명히 원격 개체의 상태를 변경합니다.

GET 현재 상태를 반환합니다 /profile/12345

PUT 일반적으로 클라이언트 측 생성 ID에 사용됩니다.

DELETE, 명백한

HEAD, 본문을 반환하지 않고 상태를 가져옵니다.

REST를 사용하면 잘 설계된 API를 통해 자체 문서화되므로 사용하기가 더 쉽습니다.

이것은 REST에 대한 훌륭한 기사 입니다. 저도 이해하는 데 도움이됩니다.

WSDL 2.0 사양에는 REST 웹 서비스에 대한 지원도 추가되었습니다. 두 세계 시나리오의 최고입니다. 문제는 WSDL 2.0이 아직 대부분의 도구에서 널리 지원되지 않는다는 것입니다. WSDL 2.0은 W3C를 권장하고 WSDL1.1은 W3C를 권장하지 않지만 도구와 개발자가 광범위하게 지원합니다. 참고 : http://www.ibm.com/developerworks/library/ws-restwsdl/

WADL (Web Application Description Language)은 RESTful 웹 서비스를 설명하는 데 사용되는 XML 어휘입니다.

WSDL과 마찬가지로 일반 클라이언트는 WADL 파일을로드하고 즉시 해당 웹 서비스의 전체 기능에 액세스 할 수 있습니다.

RESTful 서비스에는 더 간단한 인터페이스가 있기 때문에 WADL은 WSDL이 RPC 스타일 SOAP 서비스에 대한 것만 큼 이러한 서비스에 거의 필요하지 않습니다.