API 역방향 호환성을위한 모범 사례

Question

JSON API와 통신하는 iPhone/iPad/Android 앱에서 작업하고 있습니다.

앱 버전의 첫 번째 출시가 완료되었으며 개발 단계가 추가로 진행되고 있습니다. 추가 단계에서 앱은 새로운 버전의 API와 통합되어야하며 사용자가 새 화면 또는 기존 화면 내에서 수정 된 동작과 같은 추가 기능에 액세스 할 수 있어야합니다. 그러나 이전 버전의 API에서는 앱이 거꾸로 있어야합니다.

이러한 요구 사항을 해결하기위한 최선의 방법은 무엇입니까? 나는 코드를 통해 확인 할 수의 수 :

if (APIVersion == 1) { 

} else if (APIVersion == 2) { 

} else if (APIVersion == ....) { 

}... 

하지만이 방법의 확장성에 대한 걱정. 팩토리 메소드가 마음에 듭니다. 그러나 이것이 나를 얼마나 멀리 가져갈 지 확신 할 수 없습니다.

덕분에, 마크

Answer 1

릴리스는 매우 드문 것입니다. 일반적으로 새 선택적 매개 변수 또는 새 메서드를 추가하는 것만으로 이전 버전과의 호환성을 얻을 수 있습니다. 예를 들어,이 방법 search 이름,하지만 지금은 당신이 작동하는 방식에 만족했다면, 당신은 다양한 방법으로 그것을 다룰 수

• 을 변경 간단한 경우 새 mode 매개 변수를 추가 할 수있는 기본값은 mode1 (이전 버전과 호환 됨)입니다. 사용자가 mode2을 제공하면 사용자가 제안한대로 if 상태로 감지합니다. 또한 보통 "모드"보다 더 나은 이름을 생각할 수 있습니다.

• 변경 사항이 큰 경우 새로운 인터페이스를 사용하는 새로운 search2 서비스를 추가 할 수 있습니다. 그런 다음 search 메소드를 사용되지 않음으로 표시합니다 (그러나 여전히 작동하며 이전 버전과 호환 가능). 일반적으로 이렇게하면 리팩터링 코드를 사용하여 거의 모든 로직이 search2 메서드 내부에 있고 이전 search 메서드가 수정 된 매개 변수를 사용하여 내부적으로 search2을 호출하고 결과를 적절하게 다시 포맷 할 수 있습니다. . 이 작업을 올바르게 수행하면 search 메소드를 더 이상 변경할 필요가 없습니다. 테이블 등을 변경할 때 search2 만 수정하면됩니다.

요점은 N+1 첫 번째 버전의 API를 배포하지 마십시오.이러한 큰 릴리스는 방법 중 하나가 아닌 ALL의 주요 변경 사항을 의미합니다. 대부분의 주요 API는 API의 버전 2를 출시하지 않았지만 여전히 버전 1을 사용하고 있지만 위의 예와 같이 API의 일부만 수정하면됩니다.

당신 API의 N+1 -ST 버전을 릴리스에 대한확신, 당신의 방법 모든 새로운 진입 점을 만들 경우. services이라는 폴더가 있다면 services-v2이라는 새 폴더를 만듭니다. services 코드를 리팩토링하여 대부분이 services-v2을 사용합니다. 잔인하다고 생각되면 N+1 -st 버전의 API가 아직 필요하지 않다고 생각합니다.

그런데 Google지도와 같은 중앙 집중식 API와 Android 같은 분산 된 API를 혼동하지 마십시오. Android는 수십억 개의 Android 서버 (각 Android 기기가 하나임)가 있기 때문에 항상 새로운 API 버전을 출시하며 모든 것이 Google에서 간단하게 원격으로 업그레이드 할 수 없습니다. 다음 버전의 Android는 이전 버전과 여전히 이전 버전과 호환되며 숫자는 새로운 기능을 나타 내기 위해서만 증가합니다. 예. Android 7.0에서 Android 3.0 용으로 빌드 된 앱을 계속 실행할 수 있습니다 (추가 경고가 표시 될 수 있지만 앱이 실행됩니다). Android 앱 개발자는 앱에 대한 최소 요구 사항을 설명하기 위해이 숫자를 사용합니다. 반면 중앙 집중식 API는 일반적으로 이전 버전과 호환되지 않는 주요 변경 사항 인을 나타 내기 위해 버전 번호를 늘립니다.

Answer 2

난 당신이 이미 우려의 분리를 가지고 같아요. 내 말은, 귀하의 응용 프로그램에 대한 데이터를 얻는 것은 모델을 통해서만 수행된다는 것입니다 (예를 들어).

그래서 모델을 변경하기 만하면됩니다.

내가 제안하는 것은 단지 하나의 진입 점이 있다는 것입니다 : "라우터"파일. 이 파일은 필요한 API 버전을 확인하고 올바른 파일을로드합니다. 이렇게하면 각 API에 대해 서로 다른 파일을 얻을 수 있습니다. "라우터"파일은 그다지 크지 않을 것이고 새로운 API 버전마다 자체 파일이 생기므로 모든 것을 혼합하지는 않습니다. "라우터"파일의 예를 들어

: 새로운 API 버전의

function dispatch() { 
    switch (APIVersion) { 
    case 1: 
     use('file.1.ext'); 
     break; 
    case 2: 
     use('file.2.ext'); 
     break; 
    case 3: 
     use('file.3.ext'); 
     break; 
    } 
}