3장. APIcast 정책

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

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

3scale 인증 캐싱은 다음과 같은 모드에서 사용할 수 있습니다.

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

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

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

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

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

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

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

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

구성 속성

정책 오브젝트 예

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

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

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

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 Filtering 기능을 활성화합니다. 서비스 정책 체인에서 정책이 활성화되면 APIcast는 3scale Referrer 정책 값을 서비스 관리 API 에 upwards AuthRep 호출로 보냅니다. 3scale Referrer 정책의 값은 호출의 참조 매개변수로 전송됩니다.

참조 필터링이 작동하는 방법에 대한 자세한 내용은 인증 패턴 아래의 참조 필터링 섹션을 참조하십시오.

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

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

다음은 정책에 필요한 구성 속성입니다.

그림 3.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 프록시 정책 사용에 대한 자세한 내용은 3.1.25절. “프록시 서비스” 을 참조하십시오.

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

다음 예제에서는 조건 정책이 다음 조건을 정의한다고 가정합니다. 요청 방법은 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"
}

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

작업을 및 또는 또는 와 결합할 수 있습니다. 이 구성은 이전 예제와 동일하게 확인되고 백엔드 헤더의 값이 추가됩니다.

{
  "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_ECDHE.lua

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

{
   "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"
                  }
               ]
            }
         }
      ]
   }
}

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

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

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 정보로 적중 지표를 늘립니다.

{
  "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
}

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

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

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

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

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

변경하려는 응답 코드의 또 다른 예는 콘텐츠 제한을 초과할 때의 응답입니다. 업스트림에서는 응답 코드가 414 이고 request-URI가 너무 긴 경우 413 페이로드가 너무 클 수 있습니다.

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

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

HTTP2 Endpoint 정책을 사용하면 요청과 APIcast를 전송하는 소비자 애플리케이션 간에 HTTP/2 프로토콜 및 GRPC(Remote Procedure call) 연결을 사용할 수 있습니다. HTTP2 끝점 정책이 제품의 정책 체인에 있는 경우 APIcast에 요청하는 소비자 애플리케이션에서 업스트림 서비스로의 전체 통신 흐름은 HTTP/2 프로토콜 및 gRPC를 사용할 수 있습니다.

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

IP Check 정책은 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 섹션에서 정책 체인 생성 을 참조하십시오.

JSON 웹 토큰(JWT) 클레임을 기반으로 JWT 클레임을 통해 리소스 대상 및 메서드 차단에 대한 새 규칙을 정의할 수 있습니다.

JWT Claim Check 정책이 리소스 및 메서드를 차단하는 경우 정책은 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 요청에 응답하며 Liquid 템플릿을 평가하는 데 사용할 수 있습니다. 3scale APIcast 또는 업스트림 정책과 결합될 때 Liquid Context Debug를 정책 체인에 배치하여 올바르게 작동합니다. 원형 참조를 방지하기 위해 정책에는 중복된 오브젝트만 포함되어 스텁 값으로 교체합니다.

정책이 활성화된 경우 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 필터 정책을 추가하여 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)의 토큰 검사 끝점을 사용하여 OIDC(OpenID Connect) 인증 옵션을 사용하는 서비스에 사용되는 JSON 웹 토큰(JWT) 토큰을 검증할 수 있습니다.

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

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

Token Introspection Endpoint의 응답에는 active 속성이 포함되어 있습니다. APIcast는 이 속성의 값을 확인합니다. 특성 값에 따라 APIcast는 호출을 승인하거나 거부합니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

API 공급자는 API 제품에 Response/Request Content Limits 정책을 추가할 수 있습니다. 이 정책을 사용하면 요청 크기를 업스트림 API로 제한할 뿐만 아니라 업스트림 API의 응답 크기를 제한할 수 있습니다. 이 정책이 없으면 요청/응답 크기가 무제한입니다.

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

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

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

역할 유형에는 정책 구성에 type 속성이 지정되는지 확인하는 두 가지 유형이 있습니다.

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

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

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

라우팅 정책을 사용하면 요청을 다른 대상 끝점으로 라우팅할 수 있습니다. 대상 끝점을 정의한 다음 정규식을 사용하여 UI에서 들어오는 요청을 라우팅할 수 있습니다.You can define target endpoints and then you will be able to route incoming requests from the UI to those using regular expressions.

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://some_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": "/"
              }
            ]
          }
        }
      ]
    }
  }

ECDHE 정책은 정책에 지정된 매핑 규칙을 사용하여 HTTP 요청의ECDHE Action 또는 Content-Type 헤더에 제공된ECDHE 작업 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 설치에 액세스할 수 있어야 합니다. 모든 배포가 완료될 때까지 기다려야 합니다.

추가 사항:

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

자리 표시자에서 [ECDHE_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

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

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

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

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

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

다음 절차를 따르십시오.

추가 사항:

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

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

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

다음과 같습니다.

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

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

업스트림 정책을 사용하면 정규식을 사용하여 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 섹션에서 정책 체인 생성 을 참조하십시오.

업스트림 연결 정책을 사용하면 3scale 설치에서 API 백엔드 서버를 구성한 방법에 따라 각 API에 대해 다음 지시문의 기본값을 변경할 수 있습니다.

업스트림 연결 정책을 구성하려면 다음을 수행합니다.

다음 절차를 따르십시오.

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

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

verify 필드가 활성화되면 정책은 업스트림 API에서 서버 인증서도 확인합니다. ca_certificates 에는 APIcast가 서버의 유효성을 확인하는 데 사용하는 ------ BEGINECDHERTIFICATE----- 및 -----END ECDHERTIFICATE-------를 포함하여 개인 정보 보안 강화된 SASL(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 Mutual TLS, 정책 구성 스키마를 확인합니다.

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

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

정책은 다음 두 가지 작업 세트를 지원합니다.

{
  "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 재작성을 적용한 후 API 백엔드에 API 캐스트가 전송하는 URI입니다.

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

다음과 같은 변환이 적용됩니다.

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

캡처를 사용하여 URL 재작성 정책은 URL 재작성 정책의 대안이며 API 백엔드에 전달하기 전에 API 요청의 URL을 다시 작성할 수 있습니다.

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

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

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

예제

Captures로 URL Rewritings 정책은 다음과 같이 구성됩니다.

{
  "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 재작성을 적용한 후 API 백엔드에 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 정책 이전이어야 합니다.