API 허브의 모든 API 리소스에는 연결된 버전이 하나 이상 있습니다. 버전을 특정 시점의 API 상태로 생각하면 됩니다. 기본적으로 버전은 그림 1에 표시된 것처럼 기본 작업 집합, 배포, 사양, 기타 속성에 따라 API를 그룹화하고 구성하는 데 도움이 됩니다.
그림 1. 각 버전에는 작업, 배포, 기타 속성이 포함될 수 있습니다.
API 허브에서 버전은 API의 논리적 그룹을 나타냅니다. 일반적으로 이러한 그룹화는 API가 수행할 수 있는 작업을 중심으로 이루어집니다. 예를 들어 Pet Store API가 있고 이 API의 첫 번째 버전을 사용하여 반려동물 추가, 반려동물 찾기, 매장에서 반려동물 삭제와 같은 기본 작업을 수행할 수 있다고 가정해 보겠습니다. 다음은 작업의 예시입니다.
버전에는 함께 배포되는 API 작업 집합을 포함하는 것이 좋습니다. 예를 들어 Pet Store API에는 추가, 찾기 및 삭제 작업이 모두 동일한 환경에 배포된 버전이 있을 수 있습니다.
버전에 대해 이해하는 또 다른 좋은 방법은 버전이 API에 대한 API 제작자의 관점을 나타낸다고 생각하면 됩니다. API는 API를 빌드한 사람들이 해당 API에 포함하여 함께 배포될 것으로 예상하는 특성과 기능의 모음입니다.
버전 생성
API 허브에 추가하려는 API의 세부정보가 OpenAPI 사양에 캡처되었다고 가정해 보겠습니다. 이 경우 API 버전에 사양을 추가할 수 있습니다. 이렇게 하면 API 허브는 사양을 파싱하고, API에 포함된 작업과 같은 정보를 여기에서 가져온 후 해당 정보를 버전과 함께 저장합니다. OpenAPI 사양이 없는 경우에도 버전을 만들 수 있지만 관련 설명 정보로 수동으로 채워야 합니다. API 허브가 Apigee API 프록시의 자동 등록을 통해 API 세부정보 파싱을 지원하는 다른 경우도 있습니다.
동일한 버전에 여러 API 사양 파일을 업로드할 수 있습니다.
새 버전을 만들어야 하는 경우
API에 새 작업이 추가되면 새 버전을 만들어야 할 수도 있고 그렇지 않을 수도 있습니다.
API 제작자가 API에 새 작업을 추가하고 이를 현재 해당 버전과 연결된 모든 배포에 배포하려 한다고 가정해 보겠습니다. 이 경우 제작자는 새 버전의 API를 만들지 않을 수 있습니다. 반면에 제작자가 이전 버전과 호환되지 않는 변경사항(브레이킹 체인지)을 수행하고 이를 새 배포와 연결하기로 선택한 경우 새 버전을 만드는 것이 좋습니다.
API 허브를 사용하면 조직의 요구사항과 특정 API 프로듀서의 요구사항에 가장 적합하도록 API 버전을 유연하게 정의하고 구성할 수 있습니다.
시스템 속성
버전에는 기본적으로 다음 시스템 속성이 포함됩니다. 설정에서 이러한 속성과 연결된 값을 수정할 수 있습니다. 자세한 내용은 속성 관리를 참조하세요.
속성
설명
수명 주기
수명 주기는 API가 개념 구상부터 지원 종료까지 진행되는 단계의 순서가 지정된 단계 집합을 나타냅니다. 일반적으로 API의 각 버전은 자신의 수명 주기를 개별적으로 통과하므로, API의 수명 주기 단계를 직접 설정할 수는 없지만 각 API 버전에 수명 주기 단계를 할당할 수 있습니다.
규정 준수
설정을 통해 팀 또는 조직에 필요한 규정 준수 세부정보를 나타내는 값을 정의할 수 있습니다. 자세한 내용은 속성 관리를 참조하세요.
인증
설정을 통해 팀 또는 조직에 필요한 인증 세부정보를 나타내는 값을 정의할 수 있습니다. 자세한 내용은 속성 관리를 참조하세요.
문서
버전이 연결된 API의 문서 링크입니다.
사용자 정의 속성
팀 또는 조직의 요구사항에 따라 버전의 커스텀 속성(이름/값 쌍)을 정의할 수 있습니다. 속성 관리를 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-03(UTC)"],[[["\u003cp\u003eAPI hub utilizes versions to represent the state of an API at a specific point in time, allowing for the organization of APIs based on operations, deployments, and attributes.\u003c/p\u003e\n"],["\u003cp\u003eA version in API hub is a logical grouping of APIs, usually centered around the operations an API can perform, such as adding, finding, and deleting a pet in a Pet Store API example.\u003c/p\u003e\n"],["\u003cp\u003eAPI hub allows the addition of OpenAPI specifications to an API version, from which it will automatically extract information, although versions can also be created manually and populated with relevant information.\u003c/p\u003e\n"],["\u003cp\u003eNew versions of an API may be created when new operations are added or when there are backwardly incompatible changes, particularly if the changes are associated with new deployments.\u003c/p\u003e\n"],["\u003cp\u003eEach API version has system attributes like Lifecycle, Compliance, Accreditation, and Documentation, which can be customized, and users can also define their own custom attributes for each version.\u003c/p\u003e\n"]]],[],null,["# Versions overview\n\n*This page\napplies to **Apigee** and **Apigee hybrid**.*\n\nThis topic\nexplains what you need to know about creating and managing versions in API hub.\n\nWhat is a version?\n------------------\n\n\nEvery API resource in API hub has at least one version associated with it. You can think of a\nversion as the state of an API at a point in time. Fundamentally, versions help you group and\norganize your APIs based on underlying sets of operations, deployments, specifications, and other attributes, as shown\nin Figure 1.\n\n**Figure 1.** Each version can have operations, deployments, and other attributes.\n\n\nIn API hub, a version represents a logical grouping of APIs. Usually, but not necessarily, this\ngrouping revolves around the operations an API can perform. For example, let's say you have\na Pet Store API, and the first version of this API lets you perform basic tasks, like adding\na pet, finding a pet, and deleting a pet from the store. These are examples of operations.\n\nIt's a good practice for a version to include a set of API operations that are deployed\ntogether. For example, a pet store API might have a version that includes add, find, and\ndelete operations, all deployed to the same environments.\n\nAnother good way to think about a version is that it\nrepresents the API producer's view of the API. It's the collection of features and\ncapabilities that the people who built the API put into it and *expect to be deployed\nwith it*.\n\nCreating versions\n-----------------\n\n\nSuppose the details of an API you want to add to API hub are captured in an OpenAPI spec.\nIf so, you can [add the spec\nto an API version](./manage-specifications#addspec). When you do, API hub parses\nthe spec and pulls information out of it, such as which operations the API includes, and stores that\ninformation with the version. If you don't have an OpenAPI spec, you can still [create a version](./manage-versions#addversion), but you'll have\nto populate it manually with relevant descriptive information. One other case where API hub\nsupports parsing of API details through the [auto-registration of Apigee API proxies](./auto-register-apigee-proxies).\n| **Note:**API hub only supports the parsing of OpenAPI specs.\n\n\nYou can upload multiple API specification files to the same version.\n| **Note:**API hub cannot guarantee the stability of an API provided by an API producer. API hub assumes that all operations contained in an API version are intended to be deployed together.\n\n### When to create a new version?\n\n\nIf new operations are added to an API, it may warrant creating a new version, or\nperhaps not.\n\n\nLet's say the API producer adds a new operation to an API and intends it to be deployed to all\nof the deployments currently associated with the version. In that case, the producer may choose\nnot to create a new version of the API. On the other hand, if the producer makes a backwardly\nincompatible change (a breaking change) and chooses to associate it with a new deployment,\nyou may wish to create a new version.\n\n\nYou can see that API hub provides flexibility for you to define and organize your API versions\nto best suit your organization's needs and the needs of specific API producers.\n\nSystem attributes\n-----------------\n\nVersions include the following system attributes by default. You can modify the values associated\nwith these attributes in Settings. For details, see [Manage attributes](./manage-attributes).\n\nUser-defined attributes\n-----------------------\n\nDepending on your team or organizational needs, you can define custom attributes (name/value pairs)\nfor versions. See [Manage attributes](/apigee/docs/apihub/manage-attributes)."]]
