ASP.Net Core WebApi 몇 가지 버 전 관리 비교
(1)기 존 시스템 을 파괴 하지 않 고 기능 을 제때에 출시 하 는 데 도움 이 된다.
(2)선택 한 고객 에 게 추가 기능 을 제공 하 는 데 도 도움 을 줄 수 있다.
API 버 전 제 어 는 서로 다른 방식 으로 제어 할 수 있 습 니 다.방법 은 다음 과 같 습 니 다.
(1)URL 에 버 전 을 추가 하거나 검색 문자열 인자 로 서
(2)사용자 정의 헤 더 와 헤 더 를 통 해
이 글 에서 여러 버 전의 ASP.NET Core Web API 를 어떻게 지원 하 는 지 살 펴 보 자.
1.asp.net 코어 웹 api 프로젝트 를 만 들 고 NuGet 패키지 참조:Install-Package Microsoft.AspNetCore.Mvc.Versioning-Version 2.0.0
프로젝트 와 설치 패키지 가 다 되 었 습 니 다.이어서 Startup.cs 의 Configure Services 방법 에 다음 코드 를 추가 해 야 합 니 다.
보시 다시 피 3 개의 다른 옵션 이 설정 되 어 있 습 니 다.
4
2.QueryString 을 통 해 버 전 관리 실현
컨트롤 러 를 열 고 ApiVersion 기능 을 추가 합 니 다.다음 코드 는 다음 과 같 습 니 다.
위의 코드 는 1.0 버 전 으로 되 어 있다.다른 네 임 스페이스 에서 같은 이름 을 가 진 컨트롤 러 클래스 를 만 들 고 API 버 전 을 2.0 버 전 으로 설정 할 수 있 습 니 다.다음 그림 에서 보 듯 이:
이렇게.현재 브 라 우 저 로 이동 하여 컨트롤 러 에 접근 합 니 다.기본 값 으로 설정 되 어 있 기 때문에 API 버 전 1.0 컨트롤 러 의 출력 을 보 셔 야 합 니 다.현재 URL 에 api-version=2 를 추가 합 니 다.api 버 전 2.0 컨트롤 러 의 출력 을 보 셔 야 합 니 다.
2.URL Path Segment 를 통 해 이 루어 집 니 다.
문자열 인 자 를 조회 하 는 것 은 유용 하지만 긴 URL 과 다른 문자열 인 자 를 조회 하 는 경우 고 통 스 러 울 수 있 습 니 다.반면 더 좋 은 방법 은 URL 경로 에 버 전 을 추가 하 는 것 이다.예 를 들 면:
마찬가지 로,루트 파 라미 터 를 모든 적 용 된 위치 로 업데이트 해 야 합 니 다.이 변경 사항 을 사용 하면 API 인터페이스 에 접근 할 때 항상 버 전 번호 가 필요 합 니 다.api/v1/values 를 통 해 버 전 1.0 에 접근 할 수 있 으 며,api/v2/values 를 통 해 버 전 2.0 에 접근 하여 URL 의 버 전 번 호 를 변경 할 수 있 습 니 다.간단 해 요.더 깨끗 해 보 여요.
테스트 결 과 는 다음 과 같다.
3.HTTP Headers 를 통 해 버 전 관리 실현
위 두 가지 방법 중 버 전 제 어 를 지원 하기 위해 URL 을 수정 해 야 합 니 다.단,api 의 URL 이 깨끗 하 기 를 원한 다 면 api 버 전 정 보 는 추가 HTTP 헤더 로 전달 할 수 있 습 니 다.이 작업 을 진행 하려 면 ApiVersionReader 옵션 을 설정 해 야 합 니 다.코드 는 다음 과 같 습 니 다:
돋 보 이 는 줄 은 header'api-version'이 현재 api 버 전 번호 의 예상 위치 임 을 알려 줍 니 다.경로 속성 에 버 전 상세 정보 가 없 는 지 확인 합 니 다.그래서 테스트 결 과 는 다음 과 같다.
2.0 을'api 버 전'에 값 으로 제공 할 때 버 전 2.0 컨트롤 러 를 호출 하고 출력 을 되 돌려 줍 니 다.
간단 하고 설치 하기 쉽다.그러나 현재 문자열 인 자 를 조회 하 는 방법 은 버 전 관리 에 도움 이 되 지 않 습 니 다.헤더 가 설정 되면 검색 문자열 인 자 를 지정 할 수 없습니다.HeaderApiVersionReader 가 아 닌 이 두 가지 상황 을 지원 하고 싶다 면 QueryStringOrHeaderApiVersionReader 를 사용 하 십시오.코드 는 다음 과 같 습 니 다:
따라서 현재 검색 문자열 파라미터 와 header 를 지원 합 니 다.기본 검색 문자열 매개 변수 이름 은 api-version 입 니 다.따라서 구조 함 수 를 비 울 수 있 지만 다른 이름 이 필요 하 다 면 제공 해 야 합 니 다.검색 문자열 파라미터 와 레이 블 에 대해 서도 다른 이름 을 사용 할 수 있 습 니 다.ReportApiVersions 를 true 로 설정 하고 응답 헤더 의 버 전 정 보 를 되 돌려 줍 니 다.다음 그림 을 보십시오.
이제 다른 몇 가지 옵션 을 살 펴 봅 시다.
MapToApiVersion 매개 변수의 사용법:
MapToApiVersion 속성 은 하나의 API 동작 을 모든 버 전에 표시 할 수 있 습 니 다.여러 버 전 을 지원 하 는 단일 컨트롤 러 라 는 얘 기다.컨트롤 러 는 버 전 3 만 지원 하 는 API 작업 방법 일 수 있 습 니 다.이 경우 MapToApiVersion 을 사용 할 수 있 습 니 다.아래 코드 좀 봐.
위 코드 는 Public string Get()이 방법 은 버 전 1.0 에서 만 지원 되 고,Public string Getv 3()방법 은 버 전 3.0 에서 만 지원 된다 는 뜻 입 니 다.
그림 도 있 고 진짜 같 고 유연 해서 마음 에 들 어 요.
Deprecated 매개 변수의 사용법:
여러 API 버 전 을 지원 할 때 일부 버 전 은 결국 시간 이 지 날수 록 버 려 집 니 다.하나 이상 의 api 버 전이 폐기 되 었 음 을 표시 하려 면 컨트롤 러 를 Deprecated 로 수정 하 십시오.API 버 전이 지원 되 지 않 는 다 는 뜻 은 아니다.너 는 여전히 이 버 전 을 호출 할 수 있다.이것 은 API 사용자 로 하여 금 다음 버 전이 앞으로 버 려 질 것 임 을 의식 하 게 하 는 것 일 뿐이다.
위 에서 Deprecated 를 TRUE 로 설정 하면 버 전 1.0 이 나중에 버 려 질 것 이 라 고 밝 혔 다.우리 의 API 인 터 페 이 스 를 방문 하면 응답 헤드 에서 다음 과 같은 정 보 를 볼 수 있 습 니 다.
ApiVersionneytral 기능 사용:
ApiVersionneytral 기능 은 이 API 가 버 전 제 어 를 지원 하지 않 는 다 고 정의 합 니 다.api 버 전 제 어 를 지원 하 든 api 버 전 제 어 를 지원 하지 않 든 구식 api 는 행위 가 똑 같은 api 에 매우 유용 합 니 다.따라서 버 전 관리 에서 끝내기 위해 ApiVersionneytral 속성 을 추가 할 수 있 습 니 다.
버 전 정보 가 져 오기(버 전 정보)
만약 에 그 버 전의 클 라 이언 트 가 방문 하고 있다 는 것 을 알 고 싶다 면 다음 코드 를 통 해 이 기능 을 실현 할 수 있 습 니 다.
다시 말 하면 여러 버 전의 API 는 효과 적 인 방식 으로 강 화 된 기능 을 내 놓 는 동시에 변경 사항 을 추적 하 는 데 도 도움 이 된다.이 글 에서 우 리 는 ASP.NET coreWEB API 에 여러 버 전에 대한 지원 을 추가 하 는 방법 을 보 았 다.nuget 패 키 지 는 문자열 파 라 메 터 를 조회 하여 버 전 관 리 를 하고 URL 에 경로 세그먼트 와 레이 블 을 추가 하 는 것 을 지원 합 니 다.버 전 단일 API 작업 과 버 전에 서 종 료 를 선택 하 는 기능 도 있다.
제3자 의 가방 을 빌려 API 의 버 전 통 제 를 실현 하지 않 을 수 있 습 니까?방법 은 있 습 니 다.뜸 들 이지 않 고 계속 내 려 다 보 세 요.
4.최종 버 전(NuGet 패키지 의 도움 을 받 지 않 음)asp.net core 웹 api 버 전 관리
코어 API 항목 새로 만 들 기:
VersionControl 폴 더 아래 에 IApplicationModelConvention 인 터 페 이 스 를 실현 한 클래스 NameSpace VersionRouting Convention 코드 를 새로 만 듭 니 다.
public class NameSpaceVersionRoutingConvention:IApplicationModelConvention
{
private readonly string apiPrefix;
private const string urlTemplate = "{0}/{1}/{2}";
public NameSpaceVersionRoutingConvention(string apiPrefix = "api")
{
this.apiPrefix = apiPrefix;
}
public void Apply(ApplicationModel application)
{
foreach (var controller in application.Controllers)
{
var hasRouteAttribute = controller.Selectors
.Any(x => x.AttributeRouteModel != null);
if (!hasRouteAttribute)
{
continue;
}
var nameSpaces = controller.ControllerType.Namespace.Split('.');
// namespace
var version = nameSpaces.FirstOrDefault(x => Regex.IsMatch(x, @"^v(\d+)$"));
if (string.IsNullOrEmpty(version))
{
continue;
}
string template = string.Format(urlTemplate, apiPrefix, version,
controller.ControllerName);
controller.Selectors[0].AttributeRouteModel = new AttributeRouteModel()
{
Template = template
};
}
}
}
5.요약:
위의 두 가지 버 전 통제 의 실현 과 대 비 를 통 해 저 는 제3자 의 가방 을 통 해 버 전 통 제 를 실현 하 는 경향 이 있 습 니 다.이런 방법 은 기능 이 더욱 강 합 니 다.이것 은 순 전 히 개인 적 인 취미 입 니 다.여러분 은 서로 다른 장면 에 따라 어떤 방식 으로 이 루어 질 지 결정 할 수 있 습 니 다.자,여기까지 말씀 드 리 겠 습 니 다.감사합니다. 도움 이 되 기 를 바 랍 니 다.많은 응원 부 탁 드 리 겠 습 니 다.
좋은 웹페이지 즐겨찾기
