웹 서비스 API 버전 관리

시간이 지남에 따라 발전 할 계획 인 고객에게 소규모 웹 서비스 API를 제공합니다. 따라서 어떤 종류의 버전 관리가 필요하지만 어떻게 그렇게하는지에 대한 정보는 찾을 수 없습니다.웹 서비스 API 버전 관리

모범 사례가 있습니까?

웹 서비스 사용자와의 호환성을 유지하면서 새로운 기능을 계속 추가 할 수 있습니까?

출처

2009-11-05 Paul Izzy

모든 API에서 매개 변수로 "API 버전 번호"를 추가 한 다음 웹 서비스 코드에서 전략 패턴을 구현합니다. 여기서 버전 번호는 사용할 전략을 지정합니다.

출처

2009-11-05 09:36:11 ian

복잡한 유형을 변경하는 방법

에 매개 변수를 변경

동일한 인수가 있으므로 동일한 WSDL이 적용됩니다. 새 버전에서 새 속성을 추가해야한다면 무엇을합니까? –

나는 일반적으로 버전 문자열을 웹 서비스 URL에 추가하여 "버전이있는 끝점"을 제공합니다. 이러한 끝점을 구현하는 코드는 차이점이 거의없고 동일한 코드로 처리 할 수 있거나 코드를 복제 할 수 있거나 그 중간에있을 수있는 경우 공유 할 수 있습니다.

다른 버전 관리 된 끝점에서도 버전 관리가 필요한 XML 스키마를 사용할 수 있습니다.

출처

2009-11-05 09:40:16 skaffman

버전 관리는 복잡한 주제이므로 먼저 설명을보다 자세하게 정의해야합니다. 호환성을 결코 깨뜨리지 않을 것이라는 보장을 인터페이스에 가지고 있지만 새로운 기능이 무엇인지에 따라 가능하지 않을 수도 있습니다. 그래서 다른 상황과 다른 절충안이 있습니다.

새로운 소비자에게 새로운 기능만을 제공하고 모든 소비자가 직접 소비자 (중개자, 프레임 워크 등)가 아닌 경우 개별 엔드 포인트 방식이 최선의 선택입니다. 휴식을 취할 수있는 기능을 추가 할 때마다 새 끝점을 만들고 새 끝점 번호를 지정한 다음 소비자가이를 확인하고 구성을 전환하도록 알려줍니다. 이 전략은 꽤 노력했지만 사실이지만 소비자에게 최신 정보를 제공해야한다는 단점이 있습니다. 또한 서비스 간 종속성이있는 경우 추적해야 할 자질구리가 될 수 있습니다. 코드가 깨진다면 (직접) 자신의 잘못이 아니라는 단점이 있습니다.

다른 주요 전략은 확장 가능 인터페이스입니다. 내가 아는 세 가지 종류가 있습니다. 첫째, 기존의 인터페이스에서 추가 할 수있는 모든 기능을 어떻게 든 가능한 서비스 도메인을 잘 설명하려고하는 인터페이스 유형입니다. 그게 어려운 것처럼 들린다면, 그렇습니다. 이 인터페이스를 완벽한 인터페이스라고 부를 수 있습니다. 모든 것이 완전히 기술되어 있지만 전체 도메인도 완전히 설명됩니다. "완벽한"것은 정말로 종이에 단지있다.

두 번째 다양성은 일반적인 인터페이스처럼 보이지만 일반적인 확장 점을 추가하는 유형입니다. WSDL에서 이는 xs : any, name-value 쌍 또는 유사한 것을 의미합니다. 이것을 기본 확장 가능 인터페이스라고 부를 수 있습니다. 할 일이 그리 어렵지는 않지만, 그것이 합병증이없는 것은 아닙니다. 확장 점은 인터페이스가 특정 툴링 (xs : any)에서 작동하기 어렵게 만들거나 명시 적으로 입력 및 출력 (이름 - 값 쌍)을 검증하는 기능을 일부 상실 할 수 있습니다. 버전 3 또는 4를 사용하기가 꽤 어렵게 만드는 방식으로 확장 점을 남용하는 것도 꽤 쉽습니다.

세 번째 버라이어티는 인터페이스를 바이트 스트림으로 변환하는 형식입니다. 이 신 인터페이스를 호출 할 수 있습니다. 그것들은 정당한 이유가 없지만, 웹 서비스를 사용하고 있다면 웹 서비스를 사용하는 이유를 묻고 싶을 수도 있습니다. 어쩌면 원시 TCP/IP 또는 기본 HTTP GET/POST에 대해 생각해야합니다. 그러나 WSDL과 XSD의 복잡성에 시달리고 단지 처음부터 시작하기를 원하지만 인프라 스트럭처의 이유로 웹 서비스에 묶여 있어야합니다. 그러나 일단이 경로를 시작하면 소비자에게 서비스를 사용하는 방법과 사용하지 않는 방법을 완전히 새로운 방식으로 설명해야하며 XSD를 사용하는 경우 기본적으로 다시 사용할 수 있습니다. 네가 시작 했어.

최상의 옵션은 "완벽한 인터페이스"를 시도한 다음 일반 확장 성 포인트를 포기하고 추가하여 이러한 모든 옵션을 알고 서비스 디자인에 접근하는 것입니다. 완벽한 인터페이스를 설계하려고하면 인터페이스뿐만 아니라 서비스를 향상시킬 수있는 것들을 배우게됩니다. 그러나 시간이 걸릴 것입니다. 그리고 그 시간을 어떻게 든 제한하지 않으면 영원히 걸릴 것입니다.

진정한 하나님 인터페이스에 약간 부족한 래퍼 인터페이스가 있습니다. 시스템에 레이어가있는 경우 인터페이스도 레이어에 있어야합니다. 레이어 B를 변경하면 레이어 C의 모든 인스턴스가 아니라 레이어 B 만 변경하려는 것입니다.

출처

2009-11-08 02:23:59 nedruod

내 마음에 드는 하늘의 모든 추상적 인 파이. –

원래의 질문에서 제공된 정보를 바탕으로 가장 구체적이라고 생각되는 사람은 정확히 무엇입니까? – HDave

가능성 중 하나는 모든 웹 서비스 작업이 일부 추상을 상속하는 유형의 매개 변수 하나만 갖도록 설계하는 것입니다 버전 번호를 저장하는 유형입니다. 이 접근법은 eBay web services platform에 의해 구현됩니다. 다음과 같은 뭔가 : 당신이 http://server/service?version=1

쉽게 요청 버전을 감지 할 수 있습니다, 그래서 당신이 이상 작동하는지 또한

<xsd:complexType name="AbstractRequestType"> 
    <xsd:attribute name="version" type="string" /> 
    .... 

<xsd:complexType name="AddCustomerRequestType"> 
    <xsd:complexContent> 
    <xsd:extension base="AbstractRequestType"> 
    .... 

then use AddCustomerRequestType as a type of only parameter 
in addCustomer web service operation.

는 HTTP는 웹 서비스 엔드 포인트 URL에 HTTP GET 매개 변수로 버전을 추가해야 할 수도 있습니다 내가 본

출처

2009-11-09 17:03:22

가장 일반적인 전략은 WSDL에서 객체의 네임 스페이스 (일반적으로 yyyy/MM[/dd]) 버전 식별을 추가하여 WSDL 버전입니다, 즉 :

targetNamespace="http://schemas.mycompany.com/2010/01/widgets"

type (types/schema) 수준 또는 전체 WSDL 수준 - <definitions> (1.1) 또는 <description> (2.0) 중 하나에서 수행 할 수 있습니다.

다소 구식하지만 IBM Developer에서 this link이 방법에 대한 이론적 근거를 제공하고, 작동 특히 버전이 증가 될 필요가있을 때 :

뒤로 버전하게 호환/비 분리 변경 :

을 새 작업 추가
새 유형 추가

명 주요 변경 :

제거하거나 이름을 바꾸는 작업이이 버전의 웹 서비스 * 정확히 *을 경우에만 작동합니다

출처

2013-09-25 13:18:23 StuartLC

웹 서비스 API 버전 관리

답변

관련 문제