WSDL을 사용하여 REST 클라이언트를 생성하는 것이 잘못된 방향입니까?

Question

인트라넷 용으로 아주 간단한 웹 서비스를 만들려고합니다. 이 서비스는 궁극적으로 DB에 대한 인터페이스가되어 회사 내의 다양한 내부 도구가 무엇을하는지 추적 할 수있게 해줍니다. 웹 서비스를 원한다고 생각합니다. 스키마를 알지 않아도 조직 내의 다양한 도구 (및 다른 언어)로 쉽게 DB를 업데이트 할 수 있습니다.

관련 REST 대 SOAP 질문 중 많은 부분을 이미 읽었습니다. https://stackoverflow.com/search?q=soap+rest을 검색했을 때 발생하지만 내 답변을 찾지 못했습니다.

내 딜레마는 WSDL의 코드 생성 기능을 사용하면서도 REST의 단순성을 원했던 것으로 보입니다. 은 SOAP을 암시하는으로 보입니다. 다양한 내부 도구 (JAVA, Perl, Python, PHP, C++)가이 서비스와 대화 할 수 있다는 것이 가장 중요하며, 이러한 언어에 대한 인터페이스 계층을 수동으로 다시 작성/유지해야 할 때 바보처럼 보일 수 있습니다. WSDL 라우트가 나를 대신 할 것입니다. WS에서 WS를 변경하고 클라이언트 스텁을 다시 생성 한 다음 스텁을 사용하는 코드에 필요한 변경을 수행합니다 (어쨌든 완료해야 할 것입니다).

예를 들어, RESTful 웹 서비스를 사용하는 JAVA로 작성된 도구가 있다고 가정 해보십시오. 도구가 특정 URL을 처리하고, 요청을 실행하고, 응답으로 무언가를 수행하고, 원하는 경우이를 일부 데이터 구조로 변환하는 특정 코드를 도구가 가지고 있다고 상상합니다. 이제 Perl 도구를 사용하여 Perl 도구를 사용한다고 말할 수 있습니다. 같은 것. 이제는 Perl 코드가 필요합니다. 특정 URL에 대한 요청이 응답을 받고, 뭔가를 처리합니다. 각 경우에 따라서 C++과 Python 및 C#에서는 코드를 공유 할 수 없습니다. 결국 나에게서 그 추악함을 많이 숨기는 래퍼 클래스/메소드로 끝날 것이다. 나는 오히려 URL, 인수, 응답 등에 대해 걱정할 필요없이 객체에 캡슐화 된 데이터를 반환하는 클래스에서 함수를 호출하려고합니다. 물론 특정 장소의 코드가 많지는 않지만 시간이 지남에 따라 합산되기 시작합니다. 그것들을 각각의 도구에 곱하십시오. 이제는 서비스에 변경을 가하면 각 CRUD 작업의 URL과 그에 따르는 모든 것을 업데이트해야합니다. WSDL이 당신에게 도움이 될 것이라고 생각합니다. 코드는 단순히 스텁과 상호 작용합니다. 스텁이하는 일은 무엇입니까? URL, 인수, 응답 - WSDL에서 스텁을 다시 생성하면 변경됩니다. 이 프로세스로 인해 코드가 손상되는 경우에도 그렇지만 적어도 요청을 작성하고 응답을 다루는 세부 사항을 다루는 모든 코드를 업데이트 할 필요는 없습니다. 이것은 정말로 문제가 아닌가? 아마 내가해야 할 일은 단지 서비스와 소수의 고객을 만들고 내가 정말로 반대하는 것을 보는 것입니다.

저는 JAVA, Perl, Python, C++ 등에서 경험이 풍부한 숙련 된 프로그래머이지만 WS 작성을 고려한 첫 번째 경험이며 다른 WS에 대한 사전 경험이 없으므로 어떤 지침을 찾고 있어요. WSDL/SOAP을 사용하고 인기 있고 간단하며 유용한 REST가 얼마나 많은지에 대해 모두 잊어 버리십니까?

Answer 1

여기서 코드 생성 문제가 발생하지 않습니다.

REST는 어떤 종류의 코드 생성도 거의 필요하지 않습니다. 단순한 JSON (또는 XML) 페이로드가있는 HTTP 요청 일뿐입니다.

기존 HTTP 라이브러리 (예 : Apache Commons 또는 Python urrlib2)를 사용합니다. 기존 JSON (또는 XML) 라이브러리를 사용합니다. (Jersey 프로젝트는 JAXB-JSON 변환이 훌륭하다).

"생성 됨"은 무엇입니까? Java와 Python의 RESTful 라이브러리는 거의 동일하며 단순히 HTTP 라이브러리를 통해 REST 요청을한다.

class OurService { 
    def getAResource(String argValue) { 
     path = { "fixed", argValue }; 
     URI uri= build_path(path); 
     return connection.get(uri) 

는 [I는 예외 처리를 남겨 두었다.]

당신은 복잡한 SOAP 인터페이스/구현 분리에 레이어하려고합니까?

---

"C에서 ++과 파이썬과 C#"... A "같은 일을하고 펄 도구"... "는 RESTful 웹 서비스를 활용하여 Java로 작성된"클라이언트.

수정.

은

수정 "여기서 코드를 공유 할 수 없습니다." 코드를 공유 할 수 없습니다. 적절한 언어로 각 클라이언트를 작성해야합니다. WSDL로부터이 코드를 생성하는 일종의 "생성자"를 작성하는 것은 (1) 엄청난 양의 작업과 (2) 불필요한 작업입니다. 각 언어에는 고유 구문 및 REST 요청을위한 고유 한 라이브러리가 있습니다. 하지만 너무 간단하고 일반적인 이유는 거의 없습니다.

파이썬 정규 예

class Some_REST_Stub(object): 
    def get_some_resource(self, arg): # This name is from the WSDL 
     uri = "http://host:port/path/to/resource/%s/" % arg # This path is from the WSDL 
     data= urllib2.open(uri) 
     return json.load(data) 

인 코드 블록은 WSDL 그것을 설명하기 위해 요구되는 것보다짧다. 이름이 메서드 이름이고 URI가 단순히 문자열이기 때문에 변경하기가 더 쉽습니다.

대부분의 언어에서 클라이언트는 대략 간단합니다. 방금 자바에서 REST 클라이언트 코드를 썼다. 그것은 더 근사하지만 일반적인 재료입니다. 요청을 작성하고 돌아 오는 JSON을 구문 분석하십시오. 그게 전부 야.

편안한 WSDL 선언은 XML을 많이 사소한 두 가지 정보를 묻는다.

• URI에 대한 "인터페이스 이름"을 제공합니다.

• 그것은, POST를 PUT 및 스텁 클래스 메소드 이름을 제공하여 DELETE, GET의 의미를 설명합니다.

많은 코드가 없으므로 많은 코드를 작성하는 데 도움이되지 않습니다. 모든 REST 요청에는 동일한 일반 HttpRequest 및 HttpResponse 구조가 있습니다. 요청에 엔티티가 포함되어 있습니다. 또한 응답에는 구문 분석해야하는 일반 엔터티가 포함되어 있습니다. 가능한 한 간단해야한다는 것이 핵심입니다. 모든 일반적인 된 JSONObject 또는 XML urlencoded를하고 문자열로 전송하기 때문에

그것은 크게 WSDL 필요가 없습니다.

"나는 차라리 대신 등 URL, 인수, 응답, 대한 걱정의 객체에 캡슐화 내 데이터를 반환하는 클래스에 함수를 호출 할 것"

올바른 경우 "스텁"클래스를 작성해야합니다. 거의 코드가 없으며 코드를 설명하는 데 필요한 WSDL보다 짧습니다.

"나는 각 CRUD 작업에 URL을 업데이트 가야하고 모두가 함께가는 서비스를 변경 할 때 지금 각 도구를 통해이를 곱합니다."

각 클라이언트의 각 언어로 스텁 클래스를 업데이트 할 수 있습니다.또는 WSDL을 업데이트 한 다음 각 클라이언트를 다시 생성 할 수 있습니다. URI는 클라이언트 코드에 간단히 캡슐화되어 있기 때문에 동일한 양의 작업처럼 보입니다.

"WSDL로 생각하면 당신에게 도움이 될 것이라고 생각합니다."

"완료되었습니다"는 명확하지 않습니다. 말과 복잡한 WSDL을 간단한 스텁 클래스로 변환 하시겠습니까? 이것이 도움이 될 수 있다고 생각합니다. WSDL이 스텁 클래스보다 큽니다. 아마도 스텁 클래스를 작성하는 것이 더 쉬울 것이라고 생각합니다. WSDL보다 짧습니다.

"코드가 단순히 스텁과 상호 작용합니다."

수정.

"누가 URL을 인수, 응답을 관심 무엇 스텁이 수행 -. 아무것도 그냥 WSDL에서 스텁을 다시 변경됩니다 경우"

슬프게도, 거의 모든 실제 프로그래밍이 필요하지 않습니다. WSDL에서 생성하는 것은 단순히 작성하는 것보다 더 많은 작업입니다. URI는 문자열입니다. 인수는 일반 JSONObject입니다. 응답은 JSONArray를 비롯한 일반적인 HttpResponses입니다. 그게 전부 야.

"나는 또한 요청을하고 응답 처리의 세부 사항을 다루는 모든 코드를 업데이트 할 필요가 없습니다."

예외를 제외하고는 흥미로운 세부 사항이 없습니다. HTTP는 간단하고 일반적인 것입니다. GET, POST, PUT 및 DELETE는 모두 거의 동일합니다.

Answer 2

Fossill,

난 당신이를 위해 SOAP을 배울 귀찮게하지 않는 것이 좋습니다. Ws- *는 매우 높은 학습 곡선을 가지고 있으며 (불필요한) 복잡성으로 인해 생존 할 수 있습니다.

당신이 REST에 매우 만족해야 당신의 기술 세트 (자바, 펄, PHP, 파이썬, C++)에서 찾는 접근 방식 (또는 적어도 HTTP 기반)를. 그리고 : 결과는 매우 빨라질 것입니다.

S.Lott이 말했듯이 코드 생성에 대해서는 걱정하지 마십시오. 너는 필요 없어. 모든 일이 나머지 http://tech.groups.yahoo.com/group/rest-discuss/ 당신은 일반적으로 즉각적인 도움을받을 : 질문

, 난 당신이 야후 그룹에 나머지-논의에 참여하시기 바랍니다.

개인적으로 WS- *을 사용하면 도움이 될만한 유스 케이스를 아직 보지 못했습니다.

월

Answer 3

당신은 유지 보수 항목입니다 가치,하지만 나는 그것의 실제 가치에 의문을 제기 코드 세대 측면.

는 WSDL 문서 나 REST 스타일의 구현을위한 자신 만의 문법 문서를 통해이라고해도, 클라이언트는 게시 된 인터페이스를 준수해야합니다. WS/SOAP (코드 생성) 개발 모델에는 더 많은 도구가있을 수 있지만, 나는 그것이 까다롭고 필요하기 때문에 그런 것 같아요.

웹 서비스의 '통합 가능성'에는 아무런 영향이 없습니다. 두 경우 모두 형식 인터페이스를 게시하는 문제입니다. 그리고 인터페이스 변경에서 구현 변경으로 이동하는 속도는 REST 스타일 서비스의 경우 더 빠를 것입니다. WS- * 코드 생성 도구를 시작하고 (그리고 함께) 싸우는 데는 시간이 걸립니다.

Answer 4

FYI-REST에는 WADL이라는 WSDL 형 자동 생성 스키마 정의가 있습니다. 그러나 거의 아무도 그것을 사용하지 않습니다.

Answer 5

Apache CXF은 REST 클라이언트에 Java 지원 기능을 제공하므로 많은 경우 완벽한 SOAP로 '코드 생성'이점을 얻을 수 있습니다.