OpenStack Api 분석 (2)
Extension Load
APIRouter Class 의 첫 번 째 일 은 Extension Manager 를 만 들 고 이 를 통 해 각종 extension 을 불 러 오 는 것 입 니 다.
위 에 Extension Manager 의 클래스 계승 관계 와 일부 기능 을 묘 사 했 는데 그 중에서 관건 적 인 함수load_extensions 는 load 를 호출 합 니 다.standard_extensions 방법, 이 방법 은 contrib 디 렉 터 리 를 옮 겨 다 닙 니 다. 이 디 렉 터 리 는 모든 extension 을 저장 하 는 곳 입 니 다. 다음은 Keyparis 를 예 로 들 어 loadstandard_extensions 함 수 는 어떤 일 을 할 것 입 니까?
최종 loadstandard_extensions 는 contrib 디 렉 터 리 의 모든 extension Manager 에 등록 하고 사용 하 는 extension 의 alias (http request 에서 사용 되 며 유일 성 을 확보 해 야 합 니 다. http 요청 에 따라 어떤 extension 의 contrller 를 찾 는 지 알 수 있 습 니 다). 구체 적 인 코드 형식 은 self. extensions [alias] = ext 입 니 다.위의 그림 은 자신 이 정의 한 extension 을 실현 하려 면 Extension Descriptor 류 를 계승 한 다음 에 네 개의 변수 name, alias, namespace, updated 를 정의 하고 상황 에 따라 get 에 충돌 할 지 여 부 를 결정 해 야 한 다 는 것 을 알려 준다.resource 와 getcontroller_extensions 함수, 새로운 Restful 자원 을 정의 하려 면 getresource 함수, 존재 하 는 Restful 자원 의 controller 를 확장 하려 면 getcontroller_exntension 함수.예 를 들 어 키 페 어 스 는 새로운 키 페 어 스 자원 을 새롭게 정의 하고 server 의 contrller 도 확장 하여 이 두 함 수 를 다시 실현 했다.
두 번 째 단 계 는 핵심 자원 을 정의 한 다음 에 routes 의 Mapper. resource 를 사용 하여 경로 와 관련 된 관 계 를 구축 하 는 것 입 니 다.mapper. resource 는 앞에서 언급 한 Rails routes 의 용법 과 같 습 니 다.
이 그림 을 보면 브 라 우 저 에서 본 url 형식 을 알 수 있 습 니 다.그리고 주의, 그 중 server. createresource 는 이러한 자원 을 WSGI APP 로 패키지 하고 self. resources 는 사전 형식의 변수 로 key 를 server, value 를 WSGI APP 로 기록 합 니 다.
위의 그림 은 controller 가 어떻게 정의 하 는 지, 어떤 기능 이 있 는 지 설명 한다. 위 글 에서 언급 한 바 와 같이 controller 는 몇 가지 유형의 구성원 함수 가 있 는데, 두 가 지 는 @ wsgi. action 또는 @ wsgi. extends 장식 기 를 사용 하여 장식 한 것 이다.controller 의 원류 중 wsgiactions 와 wsgiextends 두 사전 은 이 방법 들 을 수집 합 니 다. key 는 action 또는 extends 의 이름 이 고 value 는 이 방법 입 니 다. http 요청 에 이러한 이름 이 있 으 면 해당 하 는 방법 에 직접 반영 합 니 다.
세 번 째 부분 은 확장 자원 에 mapper. resource 를 사용 하 는 것 입 니 다.첫 번 째 단 계 는 모든 확장 자원 을 불 러 왔 습 니 다. 세 번 째 단 계 는 확장 관리자 의 self. extensions 사전 을 옮 겨 다 니 며 모든 extensions 를 가 져 왔 습 니 다. 이 extensions 가 새로운 자원 을 정의 하면 추출 하고 이 자원 이 self. resource 의 특정한 자원 에 계승 되 었 는 지 판단 한 다음 이 자원 을 WSGI APP 로 밀봉 하여 경로 규칙 을 만 듭 니 다.
네 번 째 단 계 는 확장 자원 에서 핵심 자원 을 확장 하 는 자원 을 처리 하고 확장 하 는 방법 을 등록 합 니 다.
HTTP Request
위의 작업 을 마 친 후 APIRouter 의 마지막 작업 은 모든 WGSI APP 를 포함 한 mapper 를 기본 Router 에 전달 하 는 것 이다. Router 류 는 모든 wgi request 의 입구 류 로 wgi request 를 받 은 후 이 요청 을 구체 적 인 WSGI APP 에 배포 하 는 것 이다.
모든 WSGI APP 는 애플 리 케 이 션 클래스 에서 계승 하여 실현 해 야 합 니 다.call_방법, 이call_방법 중 http 에서 요청 한 URL 에 따라 controller 에 대응 하 는 방법 을 표시 합 니 다.
구체 적 인 예 를 살 펴 보 자. 예 를 들 어
nova keypair-list
이 api 의 상대 url /os-keypairs
을 볼 수 있 습 니 다. nova - api 는 요청 을 받 은 후 os - keypars 키워드 에 따라 collection 이 os - keypars 인 WSGI APP 에 배포 한 다음 최종 함수 호출 을 완료 합 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
기상청 API를 사용한 비오는 날만 알려주는 LINE Notify 작성지금까지 기상청의 기상 데이터는 스크래핑을 하는 것으로 밖에 얻을 수 없었습니다만, 1개월 정도 전에 기상청 HP가 API화했다(엄밀한 API가 아닌 것 같다)라고 하는 것으로 조속히 사용해 가려고 생각합니다. 이번...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.