4장. APIcast 정책

관리 포털에서 각 3scale API 제품에 대해 하나 이상의 정책을 활성화할 수 있습니다.

3scale Auth 캐싱 정책에서는 APIcast에 대한 인증 호출을 캐시합니다. 운영 모드를 선택하여 캐시 작업을 구성할 수 있습니다.

3scale Auth 캐싱은 다음 모드에서 사용할 수 있습니다.

1. Strict - 인증된 호출만 캐시합니다.

"strict" 모드는 권한 있는 호출만 캐시합니다. 정책이 "strict" 모드에서 실행되고 있고 호출이 실패하거나 거부되면 정책은 캐시 항목을 무효화합니다. 백엔드에 연결할 수 없게 되면 캐시된 상태와 관계없이 모든 캐시된 호출이 거부됩니다.

2. 복원력 - 백엔드가 중단될 때 마지막 요청에 따라 인증됩니다.

"Resilient" 모드는 권한 있고 거부된 호출을 모두 캐시합니다. 정책이 "resilient" 모드에서 실행 중인 경우 실패한 호출은 기존 캐시 항목을 무효화하지 않습니다. 백엔드에 연결할 수 없게 되면 캐시 조회가 캐시된 상태에 따라 계속 인증되거나 거부됩니다.

3. allow - 백엔드가 다운되면 이전 및 거부되지 않는 한 모든 것을 허용합니다.

"허용" 모드는 권한 있는 호출과 거부된 호출을 모두 캐시합니다. 정책이 "허용" 모드에서 실행 중인 경우 캐시된 호출은 캐시된 상태에 따라 계속 거부되거나 허용됩니다. 그러나 새 호출은 권한 있는 것으로 캐시됩니다.

4. none - 캐싱을 비활성화합니다.

"없음" 모드는 캐싱을 비활성화합니다. 이 모드는 정책을 활성 상태로 유지하지만 캐싱을 사용하지 않으려는 경우에 유용합니다.

구성 속성

정책 오브젝트 예

{
  "name": "caching",
  "version": "builtin",
  "configuration": {
    "caching_type": "allow"
  }
}

정책을 구성하는 방법에 대한 자세한 내용은 문서의 정책 체인 생성 섹션을 참조하십시오.

3scale Batcher 정책은 표준 APIcast 권한 부여 메커니즘에 대한 대안을 제공하며, 이 메커니즘에서 APIcast가 수신하는 각 API 요청에 대해 3scale 백엔드(Service Management API)를 호출합니다.

3scale Batcher 정책은 권한 부여 상태를 캐시하고 사용 보고서를 일괄 처리하여 3scale 백엔드에 대한 요청 수를 크게 줄입니다. 3scale Batcher 정책을 사용하면 대기 시간을 줄이고 처리량을 늘려 APIcast 성능을 개선할 수 있습니다.

3scale Batcher 정책이 활성화되면 APIcast는 다음 권한 부여 흐름을 사용합니다.

3scale Batcher 정책은 처리량을 개선하지만 정확도가 감소합니다. 사용량 제한과 현재 사용률은 3scale에 저장되고 APIcast는 3scale 백엔드를 호출할 때 올바른 권한 부여 상태만 가져올 수 있습니다. 3scale Batcher 정책이 활성화되면 APIcast가 3scale에 호출을 보내지 않는 기간이 있습니다. 이 기간 동안 호출을 수행하는 애플리케이션은 정의된 제한을 초과할 수 있습니다.

처리량이 속도 제한의 정확성보다 중요한 경우 높은 로드 API에 이 정책을 사용합니다. 3scale Batcher 정책은 보고 빈도 및 권한 부여 TTL이 속도 제한 기간보다 훨씬 적을 때 정확도로 더 나은 결과를 제공합니다. 예를 들어, 제한이 일별이고 보고 빈도 및 권한 부여 TTL이 몇 분으로 구성된 경우입니다.

3scale Batcher 정책은 다음 구성 설정을 지원합니다.

3scale Referrer 정책을 사용하면 Referrer 필터링 기능을 사용할 수 있습니다. 서비스 정책 체인에서 정책을 활성화하면 APIcast는 3scale Referrer 정책 값을 서비스 관리 API 에 upwards AuthRep 호출으로 보냅니다. 3scale Referrer 정책 값은 호출의 referrer 매개변수로 전송됩니다.

Referrer Filtering 작동 방식에 대한 자세한 내용은 인증 패턴 의 참조 섹션을 참조하십시오.

익명 액세스 정책은 인증 없이 서비스를 노출합니다. 예를 들어 인증 매개 변수를 전송하도록 조정할 수 없는 레거시 애플리케이션에 유용할 수 있습니다. 익명 액세스 정책은 API Key 및 App Id / App Key 인증 옵션 만 사용하는 서비스를 지원합니다. 인증 정보가 제공되지 않은 API 요청에 대해 정책을 활성화하면 APIcast는 정책에 구성된 기본 인증 정보를 사용하여 호출에 권한을 부여합니다. API 호출을 인증하려면 구성된 인증 정보가 있는 애플리케이션이 있어야 하며 활성 상태여야 합니다.

애플리케이션 계획을 사용하여 기본 자격 증명에 사용되는 애플리케이션에 대한 속도 제한을 구성할 수 있습니다.

정책에 필요한 구성 속성은 다음과 같습니다.

그림 4.1. 익명 액세스 정책

Camel 서비스 정책을 사용하여 3scale 트래픽이 정의된 Apache Camel 프록시를 통해 전송되는 HTTP 프록시를 정의할 수 있습니다. 이 경우 Camel은 역방향 HTTP 프록시로 작동합니다. 여기서 APIcast는 트래픽을 Camel로 전송하고 Camel은 트래픽을 API 백엔드로 보냅니다.

다음 예제에서는 트래픽 흐름을 보여줍니다.

3scale 백엔드로 전송된 모든 APIcast 트래픽은 Camel 프록시를 사용하지 않습니다. 이 정책은 Camel 프록시와 APIcast와 API 백엔드 간의 통신에만 적용됩니다.

프록시를 통해 모든 트래픽을 보내려면 HTTP_PROXY 환경 변수를 사용해야 합니다.

"policy_chain": [
    {
      "name": "apicast.policy.apicast"
    },
    {
      "name": "apicast.policy.camel",
      "configuration": {
          "all_proxy": "http://192.168.15.103:8080/",
          "http_proxy": "http://192.168.15.103:8080/",
          "https_proxy": "http://192.168.15.103:8443/"
      }
    }
]

all_proxy 값은 http_proxy 또는 https_proxy 가 정의되지 않은 경우 사용됩니다.

일반 HTTP 프록시 정책 사용에 대한 자세한 내용은 4.1.25절. “프록시 서비스” 을 참조하십시오.

조건부 정책은 정책 체인이 포함되어 있으므로 다른 APIcast 정책과 다릅니다. 각 nginx 단계에서 평가되는 조건을 정의합니다(예: 액세스,재작성,로그 등). 조건이 true이면 조건 정책은 체인에 포함된 각 정책에 대해 해당 단계를 실행합니다.

다음 예제에서는 Conditional Policy에서 다음 조건을 정의한다고 가정합니다. request 메서드는 POST입니다.

APIcast --> Caching --> Conditional --> Upstream

                             |
                             v

                          Headers

                             |
                             v

                       URL Rewriting

이 경우 요청이 POST 인 경우 각 단계의 실행 순서는 다음과 같습니다.

요청이 POST 가 아닌 경우 각 단계의 실행 순서는 다음과 같습니다.

이 예에서는 요청 경로가 /example_path 인지 확인합니다.

{
  "left": "{{ uri }}",
  "left_type": "liquid",
  "op": "==",
  "right": "/example_path",
  "right_type": "plain"
}

왼쪽 및 오른쪽 피연산자는 모두 liquid 또는 일반 문자열로 평가할 수 있습니다. 일반 문자열이 기본값입니다.

작업을 및 또는 또는 와 결합할 수 있습니다. 이 구성은 이전 예와 Backend 헤더 값과 동일한지 확인합니다.

{
  "operations": [
    {
      "left": "{{ uri }}",
      "left_type": "liquid",
      "op": "==",
      "right": "/example_path",
      "right_type": "plain"
    },
    {
      "left": "{{ headers['Backend'] }}",
      "left_type": "liquid",
      "op": "==",
      "right": "test_upstream",
      "right_type": "plain"
    }
  ],
  "combine_op": "and"
}

자세한 내용은 정책 구성 스키마를 참조하십시오.

업데이트된 변수 목록은 여기에서 확인할 수 있습니다. ngx_variable.lua

이 예제에서는 요청의 Backend 헤더가 스테이징 인 경우 업스트림 정책을 실행합니다.

{
   "name":"conditional",
   "version":"builtin",
   "configuration":{
      "condition":{
         "operations":[
            {
               "left":"{{ headers['Backend'] }}",
               "left_type":"liquid",
               "op":"==",
               "right":"staging"
            }
         ]
      },
      "policy_chain":[
         {
            "name":"upstream",
            "version": "builtin",
            "configuration":{
               "rules":[
                  {
                     "regex":"/",
                     "url":"http://my_staging_environment"
                  }
               ]
            }
         }
      ]
   }
}

콘텐츠 캐싱 정책을 사용하면 사용자 지정 조건에 따라 캐싱을 활성화하고 비활성화할 수 있습니다. 이러한 조건은 정책에서 업스트림 응답을 사용할 수 없는 클라이언트 요청에만 적용할 수 있습니다.

콘텐츠 캐싱 정책이 정책 체인에 있는 경우 APIcast는 요청 업스트림을 보내기 전에 HEAD 요청을 GET 요청으로 변환합니다. 이 변환을 원하지 않는 경우 정책 체인에 콘텐츠 캐싱 정책을 추가하지 마십시오.

cache-control 헤더가 전송되면 APIcast에서 설정한 시간 초과보다 우선합니다.

다음 예제 구성은 Method가 GET인 경우 응답을 캐시합니다.

{
  "name": "apicast.policy.content_caching",
  "version": "builtin",
  "configuration": {
    "rules": [
      {
        "cache": true,
        "header": "X-Cache-Status-POLICY",
        "condition": {
          "combine_op": "and",
          "operations": [
            {
              "left": "{{method}}",
              "left_type": "liquid",
              "op": "==",
              "right": "GET"
            }
          ]
        }
      }
    ]
  }
}

CORS(Cross Origin Resource Sharing) 요청 처리 정책을 사용하면 다음을 지정할 수 있으므로 CORS 동작을 제어할 수 있습니다.

CORS 요청 처리 정책은 지정되지 않은 모든 CORS 요청을 차단합니다.

구성 속성

정책 오브젝트 예

{
  "name": "cors",
 "version": "builtin",
 "configuration": {
   "allow_headers": [
     "App-Id", "App-Key",
     "Content-Type", "Accept"
   ],
   "allow_credentials": true,
   "allow_methods": [
     "GET", "POST"
   ],
   "allow_origin": "https://example.com",
   "max_age" : 200
  }
}

정책을 구성하는 방법에 대한 자세한 내용은 3scale API Management 관리 포털의 정책 체인 수정을 참조하십시오.

Custom Metrics 정책은 업스트림 API에서 보낸 응답 후 지표를 추가하는 가용성을 추가합니다. 이 정책의 주요 사용 사례는 응답 코드 상태, 헤더 또는 다른 NGINX 변수를 기반으로 메트릭을 추가하는 것입니다.

{
  "name": "apicast.policy.custom_metrics",
  "configuration": {
    "rules": [
      {
        "metric": "error",
        "increment": "{{ resp.headers['increment'] }}",
        "condition": {
          "operations": [
            {
              "right": "{{status}}",
              "right_type": "liquid",
              "left": "400",
              "op": "=="
            }
          ],
          "combine_op": "and"
        }
      }
    ]
  }
}

이 정책은 업스트림 API에서 200 상태를 반환하는 경우 status_code 정보를 사용하여 hits 메트릭을 늘립니다.

{
  "name": "apicast.policy.custom_metrics",
  "configuration": {
    "rules": [
      {
        "metric": "hits_{{status}}",
        "increment": "1",
        "condition": {
          "operations": [
            {
              "right": "{{status}}",
              "right_type": "liquid",
              "left": "200",
              "op": "=="
            }
          ],
          "combine_op": "and"
        }
      }
    ]
  }
}

Echo 정책은 들어오는 요청을 선택적 HTTP 상태 코드와 함께 클라이언트에 다시 출력합니다.

구성 속성

정책 오브젝트 예

{
  "name": "echo",
  "version": "builtin",
  "configuration": {
    "status": 404,
    "exit": "request"
  }
}

정책을 구성하는 방법에 대한 자세한 내용은 설명서의 3scale API Management 섹션에서 정책 체인 생성 을 참조하십시오.

Edge 제한 정책은 백엔드 API로 전송되는 트래픽에 대해 유연한 속도 제한을 제공하는 것을 목표로 하며 기본 3scale 권한 부여와 함께 사용할 수 있습니다. 정책에서 지원하는 사용 사례의 몇 가지 예는 다음과 같습니다.

서비스별 제한 범위를 지정하거나 전역적으로 지정할 수 있습니다.

key 는 다음 속성으로 정의된 오브젝트입니다.

각 제한에는 유형에 따라 다른 일부 매개변수도 있습니다.

각 서비스에 대해 여러 제한을 정의할 수 있습니다. 여러 제한이 정의되면 요청이 거부되거나 하나 이상의 제한에 도달하는 경우 지연될 수 있습니다.

{
  "key": { "name": "{{ jwt.sub }}", "name_type": "liquid" },
  "count": 10,
  "window": 60
}

리쿼드 지원에 대한 자세한 내용은 5.1절. “정책에서 변수 및 필터 사용” 을 참조하십시오.

condition 은 다음 속성으로 정의됩니다.

"condition": {
  "combine_op": "and",
  "operations": [
    {
      "op": "==",
      "right": "GET",
      "left_type": "liquid",
      "left": "{{ http_method }}",
      "right_type": "plain"
    }
  ]
}

헤더 조정 정책을 사용하면 기존 헤더를 수정하거나 추가 헤더를 정의하여 들어오는 요청 또는 응답에서 추가하거나 제거할 수 있습니다. 응답 헤더와 요청 헤더를 모두 수정할 수 있습니다.

헤더 조정 정책은 다음 구성 매개변수를 지원합니다.

각 작업은 다음 매개변수로 구성됩니다.

정책 오브젝트 예

{
  "name": "headers",
  "version": "builtin",
  "configuration": {
    "response": [
      {
        "op": "add",
        "header": "Custom-Header",
        "value_type": "plain",
        "value": "any-value"
      }
    ],
    "request": [
      {
        "op": "set",
        "header": "Authorization",
        "value_type": "plain",
        "value": "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
      },
      {
        "op": "set",
        "header": "Service-ID",
        "value_type": "liquid",
        "value": "{{service.id}}"
      }
    ]
  }
}

정책을 구성하는 방법에 대한 자세한 내용은 설명서의 3scale API Management 섹션에서 정책 체인 생성 을 참조하십시오.

API 공급자는 API 제품에 HTTP 상태 코드 덮어쓰기 정책을 추가할 수 있습니다. 이 정책을 사용하면 지정하는 응답 코드로 업스트림 응답 코드를 변경할 수 있습니다. 3scale은 HTTP 상태 코드 덮어쓰기 정책을 업스트림 서비스에서 보낸 응답 코드에 적용합니다. 즉, 3scale이 노출하는 API에서 상황에 맞지 않는 코드를 반환하는 경우 HTTP 상태 코드 덮어쓰기 정책을 구성하여 애플리케이션에 의미 있는 응답 코드로 해당 코드를 변경할 수 있습니다.

정책 체인에서 변경하려는 응답 코드를 생성하는 모든 정책은 HTTP 상태 코드 덮어쓰기 정책 앞에 있어야 합니다. 변경하려는 상태 코드를 생성하는 정책이 없는 경우 HTTP 상태 코드 덮어쓰기 정책의 정책 체인 위치는 중요하지 않습니다.

관리 포털에서 제품의 정책 체인에 HTTP 상태 코드 덮어쓰기 정책을 추가합니다. 정책 체인에서 정책을 클릭하여 변경하려는 업스트림 응답 코드와 대신 반환하려는 응답 코드를 지정합니다. 덮어쓰려는 각 추가 업스트림 응답 코드에 대해 더하기 기호를 클릭합니다. 예를 들어 HTTP 상태 코드 덮어쓰기 정책을 사용하여 업스트림 201, "Created", 응답 코드, 200, "OK" 응답 코드를 변경할 수 있습니다.

변경하려는 응답 코드의 또 다른 예는 콘텐츠 제한을 초과할 때의 응답입니다. 업스트림에서는 응답 코드가 414 인 요청 코드가 너무 길면 페이로드 413 을 너무 크게 반환할 수 있습니다.

관리 포털에서 HTTP 상태 코드 덮어쓰기 정책을 추가하는 대안은 정책 체인 구성 파일과 함께 3scale API를 사용하는 것입니다.

{
  "name": "statuscode_overwrite",
  "version": "builtin",
  "configuration": {
    "http_statuses": [
      {
        "upstream": 201,
        "apicast": 200
      },
      {
        "upstream": 413,
        "apicast": 414
      }
    ]
  }
}

HTTP2 끝점 정책은 요청과 APIcast를 보내는 소비자 애플리케이션 간에 HTTP/2 프로토콜 및 원격 프로시저 호출(gRPC) 연결을 활성화합니다. HTTP2 끝점 정책이 제품의 정책 체인에 있는 경우 요청을 수행하는 소비자 애플리케이션에서 업스트림 서비스에 대한 전체 통신 흐름은 HTTP/2 프로토콜 및 gRPC를 사용할 수 있습니다.

HTTP2 끝점 정책이 정책 체인에 있는 경우:

IP 확인 정책은 IP 목록을 기반으로 요청을 거부하거나 허용하는 데 사용됩니다.

구성 속성

정책 오브젝트 예

{
  "name": "ip_check",
  "configuration": {
    "ips": [ "3.4.5.6", "1.2.3.0/4" ],
    "check_type": "blacklist",
    "client_ip_sources": ["X-Forwarded-For", "X-Real-IP", "last_caller"],
    "error_msg": "A custom error message"
  }
}

정책을 구성하는 방법에 대한 자세한 내용은 설명서의 3scale API Management 섹션에서 정책 체인 생성 을 참조하십시오.

JWT(JSON 웹 토큰) 클레임에 따라 JWT 클레임 검사를 사용하면 리소스 대상 및 메서드를 차단하는 새 규칙을 정의할 수 있습니다.

JWT 클레임 검사 정책이 리소스를 차단하고 있는 경우 정책은 JWT 작업도 검증합니다. 또는 메서드 리소스가 일치하지 않으면 요청이 백엔드 API로 계속됩니다.

예: GET 요청의 경우 JWT에는 요청이 거부되지 않는 경우 admin으로 역할 클레임이 있어야 합니다. 반면, 비 GET 요청은 JWT 작업을 검증하지 않으므로 JWT 제약 조건 없이 POST 리소스가 허용됩니다.

{
  "name": "apicast.policy.jwt_claim_check",
  "configuration": {
      "error_message": "Invalid JWT check",
      "rules": [
          {
              "operations": [
                  {"op": "==", "jwt_claim": "role", "jwt_claim_type": "plain", "value": "admin"}
              ],
              "combine_op":"and",
              "methods": ["GET"],
              "resource": "/resource",
              "resource_type": "plain"
          }
      ]
  }
}

이 정책은 컨텍스트에서 사용 가능한 오브젝트 및 값을 포함하는 JSON 을 사용하여 API 요청에 응답하고 리쿼리드 템플릿을 평가하는 데 사용할 수 있습니다. 3scale APIcast 또는 업스트림 정책과 결합할 때 리쿼드 컨텍스트 디버그를 정책 체인에 배치하여 올바르게 작동해야 합니다. 순환 참조를 피하기 위해 정책에 중복된 오브젝트만 포함되고 스텁 값으로 대체됩니다.

정책이 활성화될 때 APIcast에서 반환하는 값의 예입니다.

    {
      "jwt": {
        "azp": "972f7b4f",
        "iat": 1537538097,
        ...
        "exp": 1537574096,
        "typ": "Bearer"
      },
      "credentials": {
        "app_id": "972f7b4f"
      },
      "usage": {
        "deltas": {
          "hits": 1
        },
        "metrics": [
          "hits"
        ]
      },
      "service": {
        "id": "2",
        ...
      }
      ...
    }

로깅 정책에는 다음 두 가지 용도가 있습니다.

로깅 정책을 액세스 로그 위치에 대한 글로벌 설정과 결합할 수 있습니다. APICAST_ACCESS_LOG_FILE 환경 변수를 설정하여 APIcast 액세스 로그의 위치를 구성합니다. 기본적으로 이 변수는 표준 출력 장치인 /dev/stdout 로 설정됩니다. 글로벌 APIcast 매개변수에 대한 자세한 내용은 APIcast 환경 변수를 참조하십시오.

또한 로깅 정책에는 다음과 같은 기능이 있습니다.

local cjson = require('cjson')
local PolicyChain = require('apicast.policy_chain')
local policy_chain = context.policy_chain

local logging_policy_config = cjson.decode([[
{
  "enable_access_logs": false,
  "custom_logging": "\"{{request}}\" to service {{service.id}} and {{service.name}}"
}
]])

policy_chain:insert( PolicyChain.load_policy('logging', 'builtin', logging_policy_config), 1)

return {
  policy_chain = policy_chain,
  port = { metrics = 9421 },
}

docker run --name apicast --rm -p 8080:8080 \
    -v $(pwd):/config \
    -e APICAST_ENVIRONMENT=/config/custom_env.lua \
    -e THREESCALE_PORTAL_ENDPOINT=https://ACCESS_TOKEN@ADMIN_PORTAL_DOMAIN \
    quay.io/3scale/apicast:master

{
  "name": "apicast.policy.logging",
  "configuration": {
    "enable_access_logs": false
  }
}

{
  "name": "apicast.policy.logging",
  "configuration": {
    "enable_access_logs": false,
    "custom_logging": "[{{time_local}}] {{host}}:{{server_port}} {{remote_addr}}:{{remote_port}} \"{{request}}\" {{status}} {{body_bytes_sent}} ({{request_time}}) {{post_action_impact}}",
  }
}

{
  "name": "apicast.policy.logging",
  "configuration": {
    "enable_access_logs": false,
    "custom_logging": "\"{{request}}\" to service {{service.id}} and {{service.serializable.name}}",
  }
}

{
  "name": "apicast.policy.logging",
  "configuration": {
    "enable_access_logs": false,
    "enable_json_logs": true,
    "json_object_config": [
      {
        "key": "host",
        "value": "{{host}}",
        "value_type": "liquid"
      },
      {
        "key": "time",
        "value": "{{time_local}}",
        "value_type": "liquid"
      },
      {
        "key": "custom",
        "value": "custom_method",
        "value_type": "plain"
      }
    ]
  }
}

{
  "name": "apicast.policy.logging",
  "configuration": {
    "enable_access_logs": false,
    "custom_logging": "\"{{request}}\" to service {{service.id}} and {{service.name}}",
    "condition": {
      "operations": [
        {"op": "==", "match": "{{status}}", "match_type": "liquid", "value": "200"}
      ],
      "combine_op": "and"
    }
  }
}

{
  "name": "apicast.policy.logging",
  "configuration": {
    "enable_access_logs": false,
    "custom_logging": "\"{{request}}\" to service {{service.id}} and {{service.name}}",
    "condition": {
      "operations": [
        {"op": "==", "match": "{{status}}", "match_type": "liquid", "value": "200"},
        {"op": "==", "match": "{{status}}", "match_type": "liquid", "value": "500"}
      ],
      "combine_op": "or"
    }
  }
}

에 대한 유지 관리 모드 정책을 사용하면 지정된 상태 코드 및 메시지를 사용하여 들어오는 요청을 거부할 수 있습니다. 유지 관리 기간이나 API를 일시적으로 차단하는 데 유용합니다.

구성 속성

다음은 사용 가능한 속성 및 기본값 목록입니다.

{
  "policy_chain": [
    {"name": "maintenance-mode", "version": "1.0.0",
    "configuration": {"message": "Be back soon..", "status": 503} },
  ]
}

{
    "name": "maintenance_mode",
    "version": "builtin",
    "configuration": {
        "message_content_type": "text/plain; charset=utf-8",
        "message": "Echo API /test is currently Unavailable",
        "condition": {
            "combine_op": "and",
            "operations": [
                {
                    "left_type": "liquid",
                    "right_type": "plain",
                    "op": "==",
                    "left": "{{ original_request.path }}",
                    "right": "/test"
                }
            ]
        },
        "status": 503
    }
}

정책을 구성하는 방법에 대한 자세한 내용은 설명서의 3scale API Management 섹션에서 정책 체인 생성 을 참조하십시오.

NGINX는 일부 요청 헤더를 자동으로 확인하고 해당 헤더를 검증할 수 없는 경우 요청을 거부합니다. 예를 들어 NGINX는 NGINX에서 검증할 수 없는 If-Match 헤더가 있는 요청을 거부합니다. NGINX가 특정 헤더의 검증을 건너뛰려면 NGINX 필터 정책을 추가합니다.

NGINX 필터 정책을 추가할 때 NGINX에서 검증을 건너뛸 하나 이상의 요청 헤더를 지정합니다. 지정하는 각 헤더에 대해 요청에 헤더를 유지할지 여부를 나타냅니다. 예를 들어 다음 JSON 코드는 NGINX Filter 정책을 추가하여 If-Match 헤더의 검증을 건너뛰지만 업스트림 서버로 전달되는 요청에 If-Match 헤더를 유지합니다.

{ "name": "apicast.policy.nginx_filters",
  "configuration": {
    "headers": [
      {"name": "If-Match", "append": true}
    ]
  }
}

다음 예제에서는 If-Match 헤더의 검증을 건너뛰지만 이 코드는 요청을 업스트림 서버로 보내기 전에 NGINX에 If-Match 헤더를 삭제하도록 지시합니다.

{ "name": "apicast.policy.nginx_filters",
  "configuration": {
    "headers": [
      {"name": "If-Match", "append": false}
    ]
  }
}

업스트림 서버로 이동하는 요청에 지정된 헤더를 추가할지 여부에 관계없이 NGINX 412 응답 코드를 통해 지정한 헤더를 검증할 수 없습니다.

이 정책은 모든 API 호출에 대해 OAuth 2.0 상호 TLS 클라이언트 인증을 실행합니다.

OAuth 2.0 상호 TLS 클라이언트 인증 정책 JSON 의 예는 다음과 같습니다.

{
  "$schema": "http://apicast.io/policy-v1/schema#manifest#",
  "name": "OAuth 2.0 Mutual TLS Client Authentication",
  "summary": "Configure OAuth 2.0 Mutual TLS Client Authentication.",
  "description": ["This policy executes OAuth 2.0 Mutual TLS Client Authentication ",
    "(https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) for every API call."
  ],
  "version": "builtin",
  "configuration": {
    "type": "object",
    "properties": { }
  }
}

OAuth 2.0 토큰 인트로스펙션 정책을 사용하면 토큰 발행자(Red Hat Single Sign-On)의 Token Introspection Endpoint를 사용하여 OpenID Connect(OIDC) 인증 옵션이 있는 서비스에 사용되는 JSON 웹 토큰(JWT) 토큰을 검증할 수 있습니다.

APIcast는 auth_type 필드에서 다음 인증 유형을 지원하여 토큰 Introspection Endpoint 및 이 끝점을 호출할 때 APIcast가 사용하는 인증 정보를 확인합니다.

auth_type 필드의 설정에 관계없이 APIcast는 기본 인증을 사용하여 토큰 인트로스펙션 호출을 승인합니다(인증: 기본 <token> 헤더입니다. 여기서 < token >은 Base64로 인코딩된 < client_id>:<client_secret > 설정입니다.

토큰 인트로스펙션 엔드포인트의 응답에는 활성 특성이 포함되어 있습니다. APIcast는 이 속성의 값을 확인합니다. 속성 값에 따라 APIcast는 호출을 승인하거나 거부합니다.

이 정책을 사용하면 토큰 캐싱을 활성화하여 동일한 JWT 토큰에 대한 모든 호출에서 Token Introspection Endpoint를 호출하지 않도록 할 수 있습니다. 토큰 인트로스펙션 정책에 대한 토큰 캐싱을 활성화하려면 max_cached_tokens 필드를 0 의 값으로 설정하여 기능을 비활성화하고 10000. 또한 max_ttl_tokens 필드의 토큰에 대해 1 에서 3600 초까지 Time to Live (TTL) 값을 설정할 수 있습니다.

API 공급자로 API 제품에 On Fail 정책을 추가할 수 있습니다. On Fail 정책이 정책 체인에 있고 지정된 API 소비자 요청에 대한 정책 실행이 실패하면 APIcast는 다음을 수행합니다.

On Fail 정책은 APIcast가 잘못된 구성 또는 사용자 정의 정책의 비호환 코드 때문에 정책을 처리할 수 없는 경우 유용합니다. 정책 체인의 On Fail 정책이 없으면 APIcast는 적용할 수 없는 정책을 건너뛰고 체인의 다른 정책을 처리하며 요청을 업스트림 API로 보냅니다. 정책 체인의 On Fail 정책을 사용하면 APIcast에서 요청을 거부합니다.

정책 체인에서 On Fail 정책은 모든 위치에 있을 수 있습니다.

관리 포털에서 제품의 정책 체인에 On Fail 정책을 추가합니다. 정책 체인에서 정책을 클릭하여 APIcast가 On Fail 정책을 적용할 때 반환할 상태 코드를 지정합니다. 예를 들어 400 을 지정할 수 있으며 이는 클라이언트의 잘못된 요청을 나타냅니다.

프록시 서비스 정책을 사용하여 정의된 프록시를 사용하여 3scale 트래픽이 전송되는 일반 HTTP 프록시를 정의할 수 있습니다. 이 경우 프록시 서비스는 역방향 HTTP 프록시로 작동합니다. 여기서 APIcast는 트래픽을 HTTP 프록시로 전송하고 프록시는 트래픽을 API 백엔드로 보냅니다.

다음 예제에서는 트래픽 흐름을 보여줍니다.

3scale 백엔드로 전송된 모든 APIcast 트래픽은 프록시를 사용하지 않습니다. 이 정책은 프록시 및 APIcast와 API 백엔드 간의 통신에만 적용됩니다.

프록시를 통해 모든 트래픽을 보내려면 HTTP_PROXY 환경 변수를 사용해야 합니다.

"policy_chain": [
    {
      "name": "apicast.policy.apicast"
    },
    {
      "name": "apicast.policy.http_proxy",
      "configuration": {
          "all_proxy": "http://foo:bar@192.168.15.103:8888/",
          "https_proxy": "http://foo:bar@192.168.15.103:8888/",
          "http_proxy": "http://foo:bar@192.168.15.103:8888/"
      }
    }
]

all_proxy 값은 http_proxy 또는 https_proxy 가 정의되지 않은 경우 사용됩니다. &lt ;username> 및 & lt;passwd&gt;는 선택 사항입니다. 다른 모든 구성 요소가 필요합니다.

Rate Limit Headers 정책은 애플리케이션이 속도 제한이 있는 애플리케이션 계획에 구독할 때 응답 메시지에 RateLimit 헤더를 추가합니다. 이러한 헤더는 구성된 요청 할당량 제한과 현재 시간 창에서 나머지 요청 할당량 및 초에 대한 유용한 정보를 제공합니다.

제품의 정책 체인에서 Rate Limit Headers 정책을 추가하는 경우 3scale APIcast 정책 앞에 있어야 합니다. 3scale APIcast 정책이 Rate Limit Headers 정책 이전의 경우 Rate Limit Headers 정책이 작동하지 않습니다.

기본적으로 Rate Limit Headers 정책이 구성되지 않았거나 애플리케이션 계획에 속도 제한이 없는 경우 응답 메시지에 속도 제한 헤더가 없습니다.

API 공급자는 응답/요청 콘텐츠 제한 정책을 API 제품에 추가할 수 있습니다. 이 정책을 사용하면 요청 크기를 업스트림 API로 제한하고 업스트림 API의 응답 크기를 제한할 수 있습니다. 이 정책이 없으면 요청/응답 크기는 무제한입니다.

이 정책은 다음과 같은 과부하를 방지하는 데 유용합니다.

요청 또는 응답에서 3scale이 Response/Request Content Limits 정책을 적용하려면 content-length 헤더가 필요합니다.

관리 포털에서 제품에 Response/Request Content Limits 정책을 추가한 후 이를 클릭하여 제한을 바이트 단위로 지정합니다. 요청 제한 또는 응답 제한을 지정하거나 둘 다 지정할 수 있습니다. 기본값인 0 은 무제한 크기를 나타냅니다.

또는 정책 체인 구성 파일을 업데이트하여 이 정책을 추가할 수 있습니다. 예를 들면 다음과 같습니다.

{
  "name": "apicast.policy.limits",
  "configuration":
  {
    "request": 100,
    "response": 100
  }
}

재시도 정책은 재시도 요청 수를 업스트림 API로 설정합니다. 재시도 정책은 서비스별로 구성되므로 사용자는 원하는 만큼 소수 또는 여러 서비스에 대한 재시도를 활성화하고 다양한 서비스에 대해 다른 재시도 값을 구성할 수 있습니다.

재시도 정책 JSON 의 예는 다음과 같습니다.

{
  "$schema": "http://apicast.io/policy-v1/schema#manifest#",
  "name": "Retry",
  "summary": "Allows retry requests to the upstream",
  "description": "Allows retry requests to the upstream",
  "version": "builtin",
  "configuration": {
    "type": "object",
    "properties": {
      "retries": {
        "description": "Number of retries",
        "type": "integer",
        "minimum": 1,
        "maximum": 10
      }
    }
  }
}

이 정책은 OpenID Connect 인증 옵션과 함께 사용할 때 역할 검사를 추가합니다. 이 정책은 RH-SSO(Red Hat Single Sign-On)에서 발행한 액세스 토큰에서 영역 역할 및 클라이언트 역할을 확인합니다. realm 역할은 3scale의 모든 클라이언트 리소스에 역할 검사를 추가하려는 경우 지정됩니다.

유형 속성이 정책 구성에 지정하는 두 가지 유형의 역할 검사가 있습니다.

동일한 정책에서 블랙리스트 와 화이트리스트 를 모두 구성할 수는 없지만, RH-SSO/Keycloak 역할 확인 정책의 인스턴스를 APIcast 정책 체인에 두 개 이상 추가할 수 있습니다.

정책 구성의 scopes 속성을 통해 범위 목록을 구성할 수 있습니다.

각 scope 오브젝트에는 다음과 같은 속성이 있습니다.

라우팅 정책을 사용하면 요청을 다른 대상 끝점으로 라우팅할 수 있습니다. 대상 끝점을 정의한 다음, 들어오는 요청을 UI에서 정규식을 사용하여 해당 요청으로 라우팅할 수 있습니다.

Liquid Context Debug
JWT Claim Check
Routing
3scale APIcast

Liquid Context Debug
Routing
3scale APIcast
JWT Claim Check

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://example.com",
          "condition": {
            "operations": [
              {
                "match": "path",
                "op": "==",
                "value": "/accounts"
              }
            ]
          }
        }
      ]
    }
  }

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://example.com",
          "condition": {
            "operations": [
              {
                "match": "header",
                "header_name": "Test-Header",
                "op": "==",
                "value": "123"
              }
            ]
          }
        }
      ]
    }
  }

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://example.com",
          "condition": {
            "operations": [
              {
                "match": "query_arg",
                "query_arg_name": "test_query_arg",
                "op": "==",
                "value": "123"
              }
            ]
          }
        }
      ]
    }
  }

JWT 클레임 test_claim 값이 123 인 경우 http://example.com 로 라우팅되는 구성입니다.

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://example.com",
          "condition": {
            "operations": [
              {
                "match": "jwt_claim",
                "jwt_claim_name": "test_claim",
                "op": "==",
                "value": "123"
              }
            ]
          }
        }
      ]
    }
  }

요청 경로가 /accounts 이고 헤더 Test-Header 값이 123 인 경우 로 라우팅하는 구성입니다.

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://example.com",
          "condition": {
            "combine_op": "and",
            "operations": [
              {
                "match": "path",
                "op": "==",
                "value": "/accounts"
              },
              {
                "match": "header",
                "header_name": "Test-Header",
                "op": "==",
                "value": "123"
              }
            ]
          }
        }
      ]
    }
  }

요청 경로가 /accounts 일 때 또는 헤더 Test-Header 값이 123 인 경우 http://example.com 로 라우팅되는 구성입니다.

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://example.com",
          "condition": {
            "combine_op": "or",
            "operations": [
              {
                "match": "path",
                "op": "==",
                "value": "/accounts"
              },
              {
                "match": "header",
                "header_name": "Test-Header",
                "op": "==",
                "value": "123"
              }
            ]
          }
        }
      ]
    }
  }

이 구성은 다음과 같은 몇 가지 규칙이 포함된 구성입니다.

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://some_upstream.com",
          "condition": {
            "operations": [
              {
                "match": "path",
                "op": "==",
                "value": "/accounts"
              }
            ]
          }
        },
        {
          "url": "http://another_upstream.com",
          "condition": {
            "operations": [
              {
                "match": "path",
                "op": "==",
                "value": "/users"
              }
            ]
          }
        }
      ]
    }
  }

이 구성은 경로가 /abc 인 경우 http://another_upstream.com 로 요청을 라우팅하고, 경로가 /def 인 경우 요청을 http://another_upstream.com 로 라우팅하고, 마지막으로 이전 규칙이 true로 평가되지 않은 경우 요청을 http://default_upstream.com 로 라우팅합니다.

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://some_upstream.com",
          "condition": {
            "operations": [
              {
                "match": "path",
                "op": "==",
                "value": "/abc"
              }
            ]
          }
        },
        {
          "url": "http://another_upstream.com",
          "condition": {
            "operations": [
              {
                "match": "path",
                "op": "==",
                "value": "/def"
              }
            ]
          }
        },
        {
          "url": "http://default_upstream.com",
          "condition": {
            "operations": []
          }
        }
      ]
    }
  }

이는 != 를 사용하는 구성입니다. 경로가 /accounts 가 아닌 경우 http://example.com 로 라우팅됩니다.

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://example.com",
          "condition": {
            "operations": [
              {
                "match": "path",
                "op": "!=",
                "value": "/accounts"
              }
            ]
          }
        }
      ]
    }
  }

이는 해당 값을 사용하여 요청을 라우팅하는 구성입니다.

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://example.com",
          "condition": {
            "operations": [
              {
                "match": "header",
                "header_name": "Test-Header",
                "op": "==",
                "value": "{{ my_var }}",
                "value_type": "liquid"
              }
            ]
          }
        }
      ]
    }
  }

이 구성은 some_host.com 을 Host 헤더의 호스트로 지정하는 구성입니다.

 {
    "name": "routing",
    "version": "builtin",
    "configuration": {
      "rules": [
        {
          "url": "http://example.com",
          "host_header": "some_host.com",
          "condition": {
            "operations": [
              {
                "match": "path",
                "op": "==",
                "value": "/"
              }
            ]
          }
        }
      ]
    }
  }

Cryostat 정책은 정책에 지정된 매핑 규칙을 사용하여 HTTP 요청의 Cryostat Action 또는 Content-Type 헤더에 제공된 Cryostat 작업 URI와 일치합니다.

구성 속성

정책 오브젝트 예

{
  "name": "soap",
  "version": "builtin",
  "configuration": {
    "mapping_rules": [
      {
        "pattern": "http://example.com/soap#request",
        "metric_system_name": "soap",
        "delta": 1
      }
    ]
  }
}

정책을 구성하는 방법에 대한 자세한 내용은 문서의 3scale API Management 섹션에서 정책 체인 생성 을 참조하십시오.

TLS 클라이언트 인증서 유효성 검사 정책을 사용하여 APIcast는 TLS 핸드셰이크를 구현하고 허용 목록에 대해 클라이언트 인증서를 검증합니다. 허용 목록에는 CA(인증 기관) 또는 일반 클라이언트 인증서만 서명한 인증서가 포함되어 있습니다. 만료된 인증서 또는 유효하지 않은 인증서의 경우 요청이 거부되고 다른 정책은 처리되지 않습니다.

클라이언트는 APIcast에 연결하여 요청을 전송하고 클라이언트 인증서를 제공합니다. APIcast는 정책 구성에 따라 들어오는 요청에 제공된 인증서의 진위 여부를 확인합니다. 업스트림에 연결할 때 사용하기 위해 자체 클라이언트 인증서를 사용하도록 APIcast를 구성할 수도 있습니다.

3scale 설치에 액세스할 수 있어야 합니다. 모든 배포가 완료될 때까지 기다려야 합니다.

추가 사항:

변경 사항을 저장하려면 정책 체인 업데이트를 클릭합니다.

자리 표시자에 [ your_user_key] 를 지정하여 적용된 정책을 확인할 수 있습니다.

curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN\?user_key\=[Your_user_key] -v --cacert ca/certs/ca.crt --cert ca/certs/client.crt --key ca/keys/client.key

curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN\?user_key\=[Your_user_key] -v --cacert ca/certs/ca.crt --cert ca/certs/server.crt --key ca/keys/server.key

curl https://api-3scale-apicast-staging.$WILDCARD_DOMAIN\?user_key\=[Your_user_key] -v --cacert ca/certs/ca.crt

변경 사항을 저장하려면 정책 체인 업데이트를 클릭합니다.

인증서 사용에 대한 자세한 내용은 Red Hat Certificate System 을 참조하십시오.

이 섹션에서는 TLS(Transport Layer Security) 종료 정책에 대한 정보를 제공합니다: 개념, 구성, 확인 및 정책에서 파일 제거.

TLS 종료 정책을 사용하면 모든 API에 대해 단일 인증서를 사용하지 않고 각 API에 대한 TLS 요청을 완료하도록 APIcast를 구성할 수 있습니다. APIcast는 클라이언트에 대한 연결을 설정하기 전에 구성 설정을 가져옵니다. 이러한 방식으로 APIcast는 정책의 인증서를 사용하여 TLS를 종료합니다. 이 정책은 다음 소스와 함께 작동합니다.

기본적으로 이 정책은 정책 체인에서 활성화되지 않습니다.

다음 절차를 따르십시오.

추가 사항:

변경 사항을 저장하려면 정책 체인 업데이트를 클릭합니다.

정책이 다음 명령과 함께 작동하는 경우 명령줄에서 테스트할 수 있습니다.

curl “${public_URL}:${port}/?user_key=${user_key}" --cacert ${path_to_certificate}/ca.pem -v

다음과 같습니다.

인증서를 제거하려면 다음을 수행합니다.

변경 사항을 저장하려면 정책 체인 업데이트를 클릭합니다.

Upstream 정책을 사용하면 정규식을 사용하여 Host 요청 헤더를 구문 분석하고 Private Base URL에 정의된 업스트림 URL을 다른 URL로 교체할 수 있습니다.

예를 들면 다음과 같습니다.

regex /foo 가 있는 정책 및 URL 필드 newexample.com 은 URL https://www.example.com/foo/123/ 을 newexample.com으로 바꿉니다.

정책 체인 참조:

정책 오브젝트 예

{
  "name": "upstream",
  "version": "builtin",
  "configuration": {
    "rules": [
      {
        "regex": "^/v1/.*",
        "url": "https://api-v1.example.com",

      }
    ]
  }
}

정책을 구성하는 방법에 대한 자세한 내용은 문서의 3scale API Management 섹션에서 정책 체인 생성 을 참조하십시오.

Upstream 연결 정책을 사용하면 백엔드 서비스 또는 중간 프록시로 열린 연결의 기본값을 변경할 수 있습니다. 모든 시간 초과 값은 초 단위입니다. http_proxy 를 사용하고 HTTP를 사용하여 API 백엔드에 액세스할 때 Upstream 연결 정책에 구성된 시간 초과는 작동하지만 HTTPS를 사용하여 https_proxy API 백엔드에 액세스할 때 작동하지 않습니다.

Upstream 상호 TLS 정책을 사용하면 구성에 설정된 인증서에 따라 APIcast와 업스트림 API 간의 상호 TLS 연결을 설정하고 검증할 수 있습니다.

verify 필드가 활성화되면 정책에서 업스트림 API에서 서버 인증서도 확인합니다. ca_certificates 에는 APIcast가 서버의 유효성을 검사하는 데 사용하는 -----BEGIN CERTIFICATE---- 및 ----END CERTIFICATE------------- 를 포함하여 개인 정보 보호 향상된 메일(PEM) 형식 인증서가 포함되어 있습니다.

정책 체인에서 업스트림 상호 TLS를 구성하려면 3scale 설치에 액세스할 수 있어야 합니다.

변경 사항을 승격하려면 다음을 수행합니다.

V # 은 승격할 구성의 버전 번호를 나타냅니다.

{
  "name": "apicast.policy.upstream_mtls",
  "configuration": {
      "certificate": "/secrets/client.cer",
      "certificate_type": "path",
      "certificate_key": "/secrets/client.key",
      "certificate_key_type": "path"
  }
}

{
  "name": "apicast.policy.upstream_mtls",
  "configuration": {
    "certificate_type": "embedded",
    "certificate_key_type": "embedded",
    "certificate": "data:application/pkix-cert;name=client.cer;base64,XXXXXXXXXXX",
    "certificate_key": "data:application/x-iwork-keynote-sffkey;name=client.key;base64,XXXXXXXX"
  }
}

추가 필드인 ca_certificates 에 대한 자세한 내용은 Upstream 상호 TLS, 정책 구성 스키마를 확인합니다.

URL 재작성 정책을 사용하면 요청 경로 및 쿼리 문자열을 수정할 수 있습니다.

3scale APIcast 정책과 결합하면 URL 재작성 정책이 정책 체인의 APIcast 정책 앞에 배치되면 APIcast 매핑 규칙이 수정된 경로에 적용됩니다. URL 재작성 정책이 정책 체인의 APIcast 뒤에 배치되면 매핑 규칙이 원래 경로에 적용됩니다.

정책은 다음 두 가지 작업을 지원합니다.

{
  "name": "url_rewriting",
  "version": "builtin",
  "configuration": {
    "query_args_commands": [
      {
        "op": "add",
        "arg": "addarg",
        "value_type": "plain",
        "value": "addvalue"
      },
      {
        "op": "delete",
        "arg": "user_key",
        "value_type": "plain",
        "value": "any"
      },
      {
        "op": "push",
        "arg": "pusharg",
        "value_type": "plain",
        "value": "pushvalue"
      },
      {
        "op": "set",
        "arg": "setarg",
        "value_type": "plain",
        "value": "setvalue"
      }
    ],
    "commands": [
      {
        "op": "sub",
        "regex": "^/api/v\\d+/",
        "replace": "/internal/",
        "options": "i"
      }
    ]
  }

APIcast로 전송되는 원래 요청 URI입니다.

https://api.example.com/api/v1/products/123/details?user_key=abc123secret&pusharg=first&setarg=original

URL 재작성을 적용한 후 APIcast가 API 백엔드에 전송하는 URI입니다.

https://api-backend.example.com/internal/products/123/details?pusharg=first&pusharg=pushvalue&setarg=setvalue

다음 변환이 적용됩니다.

정책을 구성하는 방법에 대한 자세한 내용은 문서의 3scale API Management 섹션에서 정책 체인 생성 을 참조하십시오.

URL Rewriting with Captures 정책은 URL 재작성 정책의 대안이며 API 백엔드에 전달하기 전에 API 요청의 URL을 다시 작성할 수 있습니다.

URL Rewriting with Captures 정책은 URL에서 인수를 검색하고 다시 작성된 URL에 해당 값을 사용합니다.

정책은 변환 구성 매개변수를 지원합니다. 요청 URL에 적용되는 변환을 설명하는 오브젝트 목록입니다. 각 tranformation 오브젝트는 다음 두 가지 속성으로 구성됩니다.

원본 URL의 쿼리 매개변수는 템플릿에 지정된 쿼리 매개변수와 병합됩니다.

예제

Captures 정책을 사용하여 URL Rewriting은 다음과 같이 구성됩니다.

{
  "name": "rewrite_url_captures",
  "version": "builtin",
  "configuration": {
    "transformations": [
      {
        "match_rule": "/api/v1/products/{productId}/details",
        "template": "/internal/products/details?id={productId}&extraparam=anyvalue"
      }
    ]
  }
}

APIcast로 전송되는 원래 요청 URI입니다.

https://api.example.com/api/v1/products/123/details?user_key=abc123secret

URL 재작성을 적용한 후 APIcast가 API 백엔드에 전송하는 URI입니다.

https://api-backend.example.com/internal/products/details?user_key=abc123secret&extraparam=anyvalue&id=123

WebSocket 정책은 업스트림 API에 WebSocket 프로토콜 연결을 활성화합니다. WebSocket 프로토콜을 활성화하려면 다음을 고려하십시오.

WebSocket 연결을 활성화하는 지정된 업스트림 API의 경우 백엔드를 http[s] 또는 ws[s] 로 정의할 수 있습니다.

정책 체인에 WebSocket 정책을 추가하는 경우 3scale API Management APIcast 정책 이전이어야 합니다.