유형 공급자 추가 권장사항

이 페이지에서는 새 API를 만들어 유형 공급자로 Deployment Manager에 추가하거나 기존 API를 유형 공급자로 추가할 경우의 권장사항을 설명합니다.

Deployment Manager에서는 API를 유형 공급자로 추가하여 API 리소스를 해당 구성에서 호출할 수 있는 유형으로 노출할 수 있습니다. 이 프로세스를 쉽게 수행하기 위해서는 API를 구성하거나 만들 때 다음과 같은 권장사항을 따르세요.

새로운 API 만들기

Deployment Manager와 통합하려는 새로운 API를 만들 때는 다음 권장사항을 따르세요.

가능하다면 커스텀 메서드를 만들지 마세요. GET, POST, PUT, DELETE 메서드와 같은 표준 REST 메서드를 따르세요. 이러한 메서드는 Deployment Manager에서 인식되어 자동으로 매핑될 수 있습니다.

Discovery API의 경우, 다음 매핑에 따라 API 메소드 이름을 지정해야 합니다.

OpenAPI 사양의 경우 표준 REST 메서드와 다른 방식으로 API 메서드 이름을 지정할 수 없습니다.

OpenAPI 사양의 경우, Deployment Manager는 RESTful 인터페이스를 식별하기 위한 두 가지 동작을 지원합니다. 첫 번째는 리소스의 모든 REST 메서드가 동일한 리소스 경로에 속하는 경우입니다.

/foo/{name}
  post:
  get:
  delete:
  put:

메서드를 구분해야 하는 경우에는 동일한 리소스 경로를 사용합니다. 예를 들어 다음은 동일한 /foo 리소스를 참조하므로 유효합니다.

/foo/
  post:
/foo/{id}
  get:
  delete:
  put:

하지만 다음은 Deployment Manager의 관점에서 서로 다른 리소스 두 개를 참조하므로 유효하지 않습니다.

/foo/
 post:
/foo-bar/{id}:
 get:
 put:
 delete:

드문 경우지만, 다음과 같이 리소스 경로 이름을 지정해야 할 수 있습니다.

foo/create
  post:

foo/delete
  delete:

이것은 RESTful 인터페이스를 식별할 수 없기 때문에 Deployment Manager 관점에서 유효하지 않습니다.

POST 및 PUT 메서드 간에 입력 및 경로 이름을 동일하게 유지하세요. 매개변수 값에도 적용됩니다. 즉, 메서드 간에 매개변수 값 구문을 동일하게 유지합니다.

예를 들어 POST 요청의 요청 본문에 email이라는 매개변수가 있으면 PUT 요청에서 동일한 매개변수의 이름을 emailAddress로 지정하지 마세요.

POST
{
    “email”: “my-email”
}

PUT
{
    “email”: “my-email@gmail.com”
}

이 유형의 동작을 추가해야 할 경우에는 고급 API 옵션을 설정하여 Deployment Manager가 이 동작을 처리할 수 있는 방법을 지정해야 합니다.

또한 POST 및 PUT 메서드의 요청 본문을 동일하게 유지합니다. GET 및 DELETE 메서드의 경우 이러한 메서드의 요청 본문이 없으므로 경로만 적용됩니다.

기존 API 통합 프로세스는 API에 따라 크게 달라질 수 있습니다. 따라서 모든 API에 대해 일반적으로 적용할 수 있는 고정된 권장사항은 존재하지 않습니다. 다음은 기존 API를 통합하기 위한 방법을 고려할 때 도움이 될 수 있는 일반적인 참고 목록입니다.

비RESTful API에 API 래퍼를 사용합니다.

기존 API가 RESTful API가 아닌 경우, REST 메서드만 노출하도록 API 래퍼를 만들 수 있습니다.
API가 거의 RESTful인 경우 API를 식별하고 업데이트합니다.

API가 거의 RESTful이고 비REST 동작이 일부만 포함된 경우, 이러한 동작을 해결하도록 API를 업데이트할 수 있습니다.
서버 생성 값에는 항상 입력 매핑이 필요합니다.

API에 API 메소드에 필요한 서버 생성 값이 포함된 경우, 서버 생성 값을 가져오고 이를 각 요청에 대해 매핑하도록 입력 매핑을 설정해야 합니다.