RESTful을 설명하기 위해 모든 리소스에 자체 URI가 있다고 말할 수 있습니다. HTTP GET, POST, PUT 및 DELETE를 사용하여 이러한 리소스에서 작업 할 수 있습니다. 모든 자원은 대표적입니다. 리소스를 사용하려는 사람은 누구나 브라우저 또는 REST 클라이언트를 통해 사용할 수 있습니다.
이것이 RESTful 아키텍처의 주요 아이디어입니다. 이 아키텍처는 인터넷에서 서비스를 허용합니다. 그렇다면이 아키텍처에 WADL이 필요한 이유는 무엇입니까? 표준 HTTP가 제공하지 않는 WADL은 무엇을 제공합니까? WADL이 존재해야하는 이유는 무엇입니까?
답변:
WADL의 목적은 계약 을 정의하는 것 입니다. 계약은 한 당사자가 다른 당사자를 호출하는 방법을 지정합니다.
웹 애플리케이션을 처음부터 만들 때 계약 및 WADL이 필요하지 않습니다 .
시스템을 다른 시스템과 통합하고 개발 팀과 명확하게 통신 할 수 있으면 계약 및 WADL이 필요하지 않습니다 (전화를 걸어 상황을 명확히 할 수 있기 때문입니다).
그러나 복잡한 엔터프라이즈 시스템을 여러 다른 회사 (또는 연방 기관)에서 유지 관리하는 다른 여러 복잡한 엔터프라이즈 시스템과 통합 할 때 가능한 한 엄격하게 정의 된 통신 계약 을 원한다고 믿습니다 . 그런 다음 WADL 또는 Open Specification이 필요합니다. 심하게 필요합니다 .
기업 배경이 약한 사람들은 전체 IT를 독립적으로 개발 된 별도의 웹 애플리케이션 모음으로 보는 경향이 있습니다. 그러나 기업의 현실은 때때로 어렵습니다. 통합해야하는 응용 프로그램을 개발하는 사람들에게 전화를 걸거나 편지를 쓸 수도없는 경우도 있습니다. 더 이상 유지되지 않는 레거시 애플리케이션과 통신하는 경우가 있습니다. 실행 만하면 제대로 통신하는 방법을 알아 내야합니다. 그런 상황에서는 계약이 필요합니다 .
실제로 클라이언트 생성은 계약 정의의 사소한 기능입니다. 그냥 장난감 일뿐입니다. Contract는 통합 규칙을 명확하게 전달하기 위해 나쁜 의사 소통자를 강제합니다. 이것이 WADL이나 Open Specification 등을 사용하는 주된 이유입니다.
Contract enforces bad communicators to communicate integration rules clearly.
WADL을 사용한다는 것은 사용자가 앞뒤로 전달하는 데이터 / 문서를 실제로 정의 할 수있을만큼 정중 할 수 있음을 의미합니다. 일부 XML 조각을 전달한다고 가정하면 실제로 정의 된 스키마의 일부일 수 있습니다.
DL을 사용하여 코드를 생성하는지 여부는 나에게별로 중요하지 않습니다. 제 생각에 중요한 것은 비즈니스 파트너 간의 인터페이스에 대해 공식적인 합의를하는 것이 중요하다는 것입니다. 전달 된 내용 이 분명하더라도 누군가 이전 인터페이스를 변경하면 나중에 누가 무엇을 수정해야하는지 식별하는 데 도움이됩니다.
데이터 형식은 동사 이름만큼이나 인터페이스의 일부입니다.
WADL은 WSDL을 기반으로 클라이언트 측 코드를 생성하기 위해 코드 생성기를 사용하는 것이 일반적인 SOAP 세계에서 온 사람들에게 어필합니다. 서버 엔드 포인트에 연결된 클라이언트 코드를 생성하기 때문에 메커니즘이 REST에서 유용하다고 생각하지 않습니다.
미디어 유형을 올바르게 정의하고 해당 미디어 유형 내에서 하이퍼 미디어를 사용한다면 WADL이 필요하지 않다고 생각합니다. 사용 가능한 끝점에 대한 설명은 미디어 유형 정의 자체에 포함되어 있습니다. 그리고 지금 스스로에게 말하고 있지만 application / xml에 사용 가능한 하이퍼 링크에 대한 정보가 포함되어 있지 않다면 BINGO라고합니다. 그렇기 때문에 application / xml 및 application / json이 REST에 적합한 미디어 유형이라고 생각하지 않습니다. XML이나 JSON을 사용하지 않는다는 것이 아니라 일반적인 미디어 유형 이름을 사용하지 마십시오.
WADL의 또 다른 매력은 REST 서비스를 문서화하기위한 것입니다. 불행히도 WADL이 서버 측 엔드 포인트를 문서화하려고 시도함에 따라 개발자를 잘못된 경로로 안내합니다. REST 서비스를 문서화하는 것은 주로 미디어 유형에 초점을 맞춰야합니다. 클라이언트 개발자는 루트 URL이 아닌 다른 URL을 몰라도 REST 클라이언트를 작성할 수 있어야합니다.
설명하기 전에 대부분의 순수한 REST 극단 주의자들이 그것을 지구 끝까지 조롱 할 것이라고 말하겠습니다. 나는 그들에게 동의하지 않습니다. 차라리 뭔가를 해내 고 싶기 때문입니다.
WADL은 웹 서비스 API에 대한 설명으로, WSDL이 SOAP 유형 웹 서비스 용인 것과 비슷하며 RESTful 인터페이스 (WSDL이 부족한 것)와 더 잘 조정되도록 설계되었습니다.
내 경험상 주요 용도는 서비스를 호출 할 수있는 클라이언트 코드를 생성 할 수 있도록하는 것입니다 (말 그대로 작업 시간을 절약하는 매우 큰 API 인 경우 편리함). 또한 REST와 유사한 인터페이스를 문서화하는 목적으로도 사용됩니다.
REST 서비스를 노출하고 싶을 때 가장 좋은 방법은 WADL을 생성하고 소비자와 공유하는 것입니다 (SOAP 기반 웹 서비스의 WSDL과 유사) .WADL은 서비스를 모든 위치에서 설명하는 데 사용됩니다.