API 파손을 방지하기 위해 일반적으로 REST 서비스 용 클라이언트 라이브러리를 개발해야합니까?

9

우리는 UI 팀이 동일한 팀에 의해 개발되지만 서비스 계층 (REST / Java)과 다른 언어 (Python / Django)로 개발 될 프로젝트가 있습니다. 각 계층의 코드는 다른 코드 리포지토리에서 종료되며 다른 릴리스주기를 따를 수 있습니다 . UI 계층의 관점에서 서비스 계층의 주요 변경 사항을 방지 / 감소시키는 프로세스를 고안하려고합니다.

UI 또는 서비스 계층을 작성할 때마다 실행되는 통합 테스트를 UI 계층 수준에서 작성하려고 생각했습니다 (Jenkins를 CI 도구로 사용하여 두 개의 Git 저장소에 코드를 작성합니다). 서비스 계층에 장애가 발생하여 커밋이 허용되지 않습니다.

서비스 계층의 개발자가 UI 계층에 존재하는 REST 서비스에 대한 클라이언트 라이브러리를 작성하고 유지하도록하는 것이 좋은 아이디어입니까? 그들의 서비스 API? 아마도 UI 코드가 작성하는 정적 유형 API의 이점이있을 것입니다. 클라이언트 라이브러리 API가 변경되면 UI 코드가 컴파일되지 않습니다 (따라서 주요 변경 사항이 있음을 곧 알게 될 것입니다). 또한 UI와 서비스 계층을 구축 할 때 여전히 통합 테스트를 실행하여 UI와 서비스 간의 통합이 여전히 작동하는지 확인합니다.

rest django

— 모범 사례
소스

6

API를 변경할 때 알려지지 않습니까? 이 경우 API 버전을 관리하는 것이 가장 좋으므로 UI에는 항상 작동하는 버전이 있습니다. 그런 다음 가능한 한 빨리 최신 API 버전으로 "업그레이드"하십시오.

— Matt S

@MattS : 동의합니다. 그러나 통신 유무에 관계없이 : 컴파일러가 코드에서 변경해야하는 모든 위치를 컴파일러에 알려 주면 변경된 API로 업그레이드하는 것이 훨씬 쉽습니다. OP는 여전히 파이썬 코드가 정적으로 유형이 지정된 API를 제공하는 방법을 알려주지 않습니다.

— Doc Brown

1

일반적으로 API 메소드가 사라질 경우, 대체 API를 사용할 수 있고 테스트되는 즉시 규칙을 선택하여 '비추천'하십시오. 이전 API는 (필수적으로) 그대로두고 메소드 시그니처 메타 데이터에 태그를 지정하거나 로깅 이벤트를 삽입하여 사용법을 명확하게 식별 할 수 있습니다.

서비스 API 내에서 로깅하는 것이 하나이지만, 클라이언트 소비에 대한 경고는 다른 것입니다. REST의 경우 견고하고 표준적인 방법이 없다고 생각합니다. FourSquare API 클라이언트는 호출 된 메소드가 성공한 경우에도 더 이상 사용되지 않는 메소드를 발견 할 수 있습니다 (HTTP 200 코드, 그러나 errorType은 '더 이상 사용되지 않음'으로 설정 됨). 소비 클라이언트에게 중단없이 API 내에서 더 이상 사용되지 않는 메소드에 대한 지식을 제공 할 수있는 합리적인 전략 일 수 있습니다.

https://developer.foursquare.com/overview/responses

API 지침 내에서 더 이상 사용되지 않는 API가 완전히 제거되는 날짜 또는 빌드 릴리스 번호를 제안하십시오. 사용 중단에 대한 전략을 구체화 할 때 제안 된 전략이 무엇인지 (더 이상 사용되지 않는 메소드를 발견하는 방법, 대체 API로 전환하는 방법, 더 이상 사용되지 않는 API를 더 이상 사용할 수없는 경우) API에 대해 소비자에게 알리고 자합니다. API 정리 중에 제거)하고 프로세스가 모든 사람에게 유익한 지 확인하기 위해 피드백을 요청합니다.

— JustinC
소스

1

API 버전 관리도 가능합니다. 새 버전이 배포되면 이전 버전도 활성 상태로두고 요청을 통한 협상을 허용하십시오. 최신 2 개 또는 3 개의 버전을 유지하면 UI 코드가 원하는대로 업그레이드 될 수 있습니다.

— 피기
소스

1

한 번에 3 개 이상의 질문이 있습니다. 하나씩 질문 해 보겠습니다.

"REST 서비스를위한 클라이언트 라이브러리를 갖는 것이 좋은 생각입니까?"

모든 UI 코드를 통해 임의의 REST 호출을 직접 산포하지 않으려는 경우 가능합니다.

"서비스 계층의 개발자가 라이브러리를 작성하고 유지하게하는 것이 좋은 생각입니까?"

이는 팀원에 따라 다릅니다. API 관리자는 서비스 계층에서 사용 가능한 사항과 UI 계층의 요구 사항을 모두 알고 있어야합니다. 따라서 서비스 계층의 사람이거나 UI 계층의 사람이거나 (크기 및 기타 작업에 따라) 두 팀과 독립적 인 사람 일 수 있습니다.

"클라이언트 라이브러리 API가 변경되면 UI 코드가 컴파일되지 않는다"는 사실로부터 이점을 얻을 수 있습니까?

UI가 파이썬으로 작성 될 것이라고 말하지 않았습니까? 정적으로 유형이 지정된 언어가 아니므로 API 변경으로 인한 즉각적인 빌드 중단을 기대하지 않습니다. 나는이 시점에서 내가 틀렸다고 가정하고 여기에 정적으로 유형이 지정된 API가 있다고 가정하면 API에 새로운 기능 (예 : 새로운 선택적 매개 변수) 을 추가 할 때 빌드 가 중단되지 않는 한 여기에 몇 가지 이점이있을 수 있습니다 . 그렇지 않으면 팀에 불필요한 오버 헤드가 많이 발생합니다.

— 닥 브라운
소스