Façade REST 서비스에 대한 사용자정의 API 구현

모바일 애플리케이션을 개발할 때는 일반적으로 먼저 사용자 인터페이스 계층으로 시작한 다음 REST 웹 서비스를 사용하여 애플리케이션을 다른 애플리케이션과 연결합니다. 이 방법은 작거나 간단한 응용 프로그램에 적합합니다. 애플리케이션이 더 커지고 여러 백엔드 서비스와 연결하려는 경우 실수로 성능 및 보안 문제가 발생할 수 있습니다.

가능한 경우 백엔드 서비스에 대한 호출 수를 줄이기 위해 외부 백엔드 서비스와 사용자 인터페이스 간에 정면 API 계층을 구축하는 것이 좋습니다. 예를 들어, 모바일 애플리케이션은 다른 REST 서비스에 대한 호출을 처리하는 façade API 계층에 대한 단일 호출을 실행하고 모든 수신 데이터를 모바일 애플리케이션에 대한 단일 응답으로 통합할 수 있습니다.

완전한 사용자정의 API 생성

Oracle Mobile Hub를 사용하여 완전한 사용자정의 API를 생성하려면

을 누르고 개발, 사이드 메뉴에서 API를 차례로 선택합니다. 초안 또는 게시됨 상태에 관계없이 API가 이미 생성된 경우 API 목록이 표시됩니다. 사용자정의 API가 존재하지 않을 경우 새 API 단추가 있는 페이지가 표시됩니다. 이미 생성한 API를 누르거나 새 API를 눌러 시작합니다.

끝점 정의

리소스를 생성하여 API의 끝점을 정의합니다. 자원은 API의 핵심입니다. 여기에는 유형, 연관된 일부 데이터, 다른 리소스와의 관계가 있으며 해당 유형에 따라 작동하는 하나 이상의 메소드가 포함됩니다. 리소스는 이미지, 텍스트 파일, 기타 리소스 모음, 논리적 트랜잭션, 프로시저 등 거의 모든 것이 될 수 있습니다.

시작하려면 끝점 탐색 링크를 누릅니다.
새 리소스를 누르고 몇 가지 기본 정보를 추가합니다.

새 리소스를 누를 때마다 최상위 레벨(루트) 리소스를 만듭니다. 하위(중첩) 리소스를 추가하려면 최상위 레벨 리소스 옆에 있는 추가(+)를 누릅니다. X를 눌러 리소스를 삭제할 수 있습니다.

주:
메소드 링크 아래의 아이콘을 참조하십시오. 리소스에 대한 메소드를 정의할 때마다 해당 리소스의 아이콘이 [메소드] 링크 아래에 나타납니다. 이러한 메소드를 바로가기로 사용하여 리소스에 대해 이미 정의된 메소드를 확인합니다. 아이콘을 누르면 [메소드] 페이지에서 해당 정의로 바로 이동합니다.
리소스 경로(기본 URI에 대한 상대 URI)를 제공합니다. 예를 들어 기본 URI가 /mobile/custom/audits/인 경우 findings 리소스(/mobile/custom/audits/findings)를 추가할 수 있습니다.
API 설명서에서 쉽게 식별할 수 있도록 리소스의 이름인 표시 이름을 제공합니다.
리소스는 API 테스트 페이지 왼쪽에 표시 이름별로 나열됩니다.
리소스에 대한 간략한 설명을 입력합니다.

설명을 입력하면 URI가 설명 필드 아래에 표시됩니다.
(선택 사항) 리소스 유형(resourcesType:)인 RAML 리소스 유형을 제공합니다. 리소스 유형을 지정할 필요가 없습니다. 리소스 유형을 사용하지만 정의되지 않은 경우 유형 링크를 누르고 정의합니다.

리소스에 대한 메소드를 생성할 때 해당 메소드의 기호가 [메소드] 링크 아래에 나타납니다. 리소스 정의를 검사해야 하는 경우 리소스에 대해 정의된 메소드를 즉시 확인할 수 있습니다. 아이콘을 눌러 해당 메소드 정의로 직접 이동합니다.

Compact Mode(New Resource의 오른쪽에 있음)로 전환하여 더 빠르게 리소스를 찾기 위해 불필요한 부분을 지울 수 있습니다. 압축 표시는 리소스 설명, 리소스 유형 및 경로를 숨깁니다.

리소스에 메소드 추가

메소드는 리소스에 대해 수행할 수 있는 작업입니다. Methods 페이지에는 한 번에 하나의 메소드가 표시됩니다. 두 개 이상의 메소드가 정의된 후 페이지 상단에 있는 메소드의 아이콘을 눌러 해당 세부 정보를 볼 수 있습니다.

메소드를 눌러 리소스에 몇 가지 메소드를 추가합니다.

정의 중인 메소드에 경로 매개변수가 있는 경우 메소드 추가 위에 표시됩니다.
1. (선택 사항) 각 메소드와 함께 경로 매개변수를 전달하려면 필수를 누릅니다.
  매개변수 이름이 표시됩니다.
2. 매개변수의 표시 이름과 예제 코드를 제공합니다.
3. 드롭다운 목록에서 매개변수에 대해 적합한 값 유형을 선택합니다.
메소드 추가를 누르고 원하는 메소드를 선택합니다.

메소드를 선택한 후에는 리소스당 한 번만 사용하므로 메소드 목록에 더 이상 나열되지 않습니다. 예를 들어, 단일 리소스에 대해 두 개의 DELETE 메소드를 정의할 수 없습니다. 정의하는 각 메소드에 대한 아이콘이 페이지 상단에 표시됩니다. 메소드 아이콘을 눌러 해당 정의로 직접 이동합니다.
(선택 사항) [설명] 필드에 메소드에 대한 간단한 설명을 입력합니다.
(선택 사항) 메소드의 표시 이름을 입력합니다.
(선택 사항) 메소드에 적용할 특성을 제공합니다.

정의된 리소스 특성이 없는 경우 끝점을 눌러 기본 리소스 페이지로 돌아가서 특성 링크를 눌러 정의합니다. 특성을 사용하여 유사한 작업 모음을 정의할 수 있습니다.

리소스에 대한 메소드를 정의한 후 해당 메소드에 대한 요청 및 응답을 정의할 수 있습니다.

메소드에 대한 요청 정의

이제 메소드를 선택했으므로 연결할 서비스의 요청을 정의합니다. 예를 들어, POST 메소드를 선택한 경우 이제 생성할 항목을 정의할 수 있습니다. 서비스로 전송할 데이터에 대한 설명이 포함된 매개변수와 요청 본문을 추가하여 이 작업을 수행합니다.

요청을 눌러 요청을 정의합니다.
매개변수 추가를 누르고 매개변수 유형(질의 또는 머리글)을 선택합니다. 메소드에 매개변수가 필요하면 필수를 선택합니다.
1. 매개변수에 이름과 표시 이름을 지정합니다.
2. 문자열, 숫자, 정수, 날짜 또는 부울 중에서 적합한 값 유형을 선택합니다.
3. (선택 사항) 끝점의 유효성을 테스트할 때 사용할 수 있는 매개변수 및 예제에 대한 설명을 제공합니다. 예를 들어, 리소스 audits가 있고 숫자 값을 사용하는 질의 매개변수 auditorID와 문자열 값을 사용하는 다른 매개변수 auditName를 추가할 수 있습니다.
```
/audits: 
  get: 
    description: | 
      Gets list of audits, organizations etc.     
    queryParameters: 
      auditorID:  
        id: Auditor ID
        description: | 
          display auditor identifier 
        type: integer 
        example: |
          1234
        required: false      
      auditName:
        displayName: auditName
        description: |
          Audit name
        example: "Payroll Process Audit"
```
  이 예에서 GET 메소드는 질의 매개변수 auditorID 및 auditName로 정의됩니다.
4. (선택 사항) 추가 속성을 눌러 중첩 속성을 매개변수에 추가합니다. 반복을 눌러 현재 매개변수의 배수를 추가합니다.
5. 매개변수 추가를 눌러 메소드에 대한 다른 최상위 레벨 매개변수를 추가합니다.
선택한 방법에 따라 매체 유형 추가를 누르고 메소드 본문을 정의합니다. 본문은 서버로 보내는 데이터를 포함합니다. 예를 들어, POST 메소드를 정의하는 경우 새 고객 목록 또는 서비스 요청과 같이 생성 중인 항목을 정의해야 합니다. GET 메소드를 정의하는 경우 매체 유형을 지정할 필요가 없도록 메소드 본문을 전송할 필요가 없습니다.
1. 메소드 본문에 대한 매체 유형(텍스트, 이미지 또는 웹 폼과 같이 전송 중인 메시지의 형식)을 선택합니다.
  유형에 따라(예: 이미지 유형에 대한 스키마를 입력하지 않음) 스키마나 예제 또는 둘 다를 추가할 수 있습니다.
  스키마를 정의할 때는 리소스에 필요한 데이터만 추가합니다. 즉, 전송 속도를 늦추고 잠재적으로 오류 가능성을 높이는 불필요한 데이터를 추가하지 마십시오.
2. (선택사항) 스키마를 누르고 편집기 창에 스키마(JSON 형식)를 입력합니다. 스키마는 본문에 대한 템플리트와 같습니다. 메시지 콘텐츠를 정의하는 데 사용됩니다.
3. (선택 사항) 예를 누르고 편집기 창에 예제(JSON 형식)를 입력합니다. 이 예제는 모의 구현에서 메소드에 대한 모의 응답으로 사용됩니다. 모의 데이터를 사용하면 메소드의 동작을 확인하는 데 도움이 될 수 있습니다. 예제에서는 audits 리소스의 POST 메소드에 정의된 대로 메시지 본문에서 전송되는 데이터에 대한 모의 값을 보여줍니다.
```
body: 
  application/json: 
    example: | 
      { 
        "Title": "Leaking Water Heater",
        "Username": "joh1017",  
        "imageLink": "storage/collections/2e029813-d1a9-4957-a69a-fbd0d7431d77/objects/6cdaa3a8-097e-49f7-9bd2-88966c45668f?user=lynn1014", 
        "Notes": "my water heater is broken"
      }                               
```
매체 유형 추가를 눌러 다른 매체 유형을 추가합니다. 메소드를 사용하지 않으려면 배너에서 X를 눌러 삭제합니다.

방법에 대한 응답 정의

요청에 따라 응답이 필요할 수도 있고 필요하지 않을 수도 있습니다. 응답은 서비스에서 결과를 반환하는 프로세스를 설명합니다. 요청한 데이터가 반환되었는지 확인하는 응답을 정의하거나 요청이 수신되었는지 여부를 확인하는 응답을 원할 수 있습니다. 응답 정의는 요청을 정의하는 것과 유사합니다. 주요 차이점은 연결 결과를 알려주는 상태 코드를 선택해야 한다는 것입니다.

응답을 눌러 하나 이상의 응답을 정의합니다.
응답 추가를 누르고 반환할 상태 코드를 선택합니다.
상태 코드 200은 기본적으로 제공되지만 원하는 코드가 아닌 경우 드롭다운 목록에서 하나를 선택합니다.
- 2xx는 연결 성공 여부를 나타냅니다.
- 3xx는 재지정이 발생했음을 나타냅니다.
- 4xx는 사용자 오류가 발생했음을 나타냅니다.
- 5xx는 서버 오류가 발생했음을 나타냅니다.
API를 사용하여 구성 중인 API의 잠재적 오류 원인을 이해하는 데 도움을 주려면 HTTP 상태 코드를 사용하여 오류 상황에 가장 적합한 코드를 반환합니다.
코드가 지정하는 내용에 대한 설명을 제공합니다.
헤더 추가를 누르고 응답 헤더 또는 질의를 선택한 다음 헤더 또는 질의의 이름과 헤더의 표시 이름 및 헤더의 적합한 값 유형을 제공합니다.
미디어 유형 추가를 누르고 응답 형식을 선택합니다. 선택한 매체 유형에 따라 요청 본문과 마찬가지로 매개변수, 스키마 또는 예를 추가할 수 있습니다.
1. 텍스트 기반 매체 유형(예: application/json 또는 text/xml)의 경우 스키마를 눌러 본문에 대한 스키마(JSON 형식)를 입력합니다.
  요청 본문과 마찬가지로 관련 데이터만 응답 본문에 추가합니다. 실제로 작업에 필요한 것보다 많은 데이터를 포함하지 마십시오.
2. 예를 눌러 응답 본문에 대한 모의 데이터(JSON 형식)를 추가합니다. 실제 데이터로 테스트하기 전에 모의 데이터를 사용하여 메소드 동작을 확인합니다.
3. 폼 기반 매체 유형(예: multipart/form-data)의 경우 매개변수 추가를 누르고 필수 매개변수인 경우 필수를 선택합니다. 그런 다음 이름을 제공하고 값 유형을 선택합니다. 선택적으로 매개변수에 이름을 지정할 수 있습니다.
4. 이미지 기반 매체 유형(예: image/png)의 경우 제공할 스키마나 속성이 없으므로 아무 작업도 수행할 필요가 없습니다.

다음 예에서는 audits 리소스의 POST 메소드에 대한 응답이 상태 코드 201로 생성되어 새 리소스가 성공적으로 생성되었음을 나타냅니다. 이 예제에서는 반환 응답 형식 application/json, 추가된 Location 헤더 및 모의 데이터를 포함하는 메시지 본문도 보여줍니다.

responses: 
  201: 
    description: | 
      The request has been fulfilled and resulted in a new resource 
      being created. The newly created resource can be referenced  
      by the URI(s)returned in the entity of the response, with the 
      most specific URI for the resource given by a Location header
      field.  

    headers:
      Location:
        displayName: Location
        description: |
          Identifies the location of the newly created resource.

        type: string
        example: |
          /20934

        required: true

    body: 
      application/json: 
        example: | 
          {
            "id": 20934,
            "title": "Lynn's Leaking Water Heater",
            "contact": {
               "name": "Lynn Adams",                 
               "street": "45 O'Connor Street",
               "city": "Ottawa", 
               "postalcode": "a1a1a1",
               "username": "johnbeta"
              },
           "status": "New",
           "driveTime": 30,
           "priority": "high",
           "notes": "My notes",
           "createdon": "2014-01-20 23:15:03 EDT",
           "imageLink": "storage/collections/2e029813-d1a9-4957-a69a-fbd0d74331d77/objects/6cdaa3a8-097e-49f7--9bd2-88966c45668f?user=lynn1014"
          }

응답을 정의할 때 끝점을 테스트하도록 결정하거나 탐색 모음에서 끝점을 눌러 기본 리소스 페이지로 돌아갈 수 있습니다. 여기서 API Designer의 다른 페이지로 이동하여 루트, 리소스 유형 또는 특성을 생성하거나 API 설명서를 추가할 수 있습니다.

메소드를 사용하지 않으려면 배너에서 X를 눌러 삭제합니다.

REST 커넥터 API 생성

REST 커넥터 API 마법사를 사용하여 커넥터 API를 생성, 구성 및 테스트합니다.

기본 작업 커넥터 API를 가져오려면 커넥터 API의 이름과 외부 서비스에 대한 URL을 적게 제공할 수 있습니다.

여기에서 다음을 수행할 수 있습니다.

액세스하려는 데이터에 대한 특정 요청 또는 응답을 형성하는 규칙을 정의합니다.
액세스 중인 서비스에 대한 클라이언트측 보안 정책을 구성합니다.
연결을 테스트하고 연결 호출 결과를 테스트합니다.

애플리케이션이 커넥터 API를 호출하고 API 및 구현을 자동으로 생성할 수 있도록 사용자정의 API 및 구현을 생성해야 합니다. 이 작업을 수동으로 수행하려면 적절한 리소스로 사용자정의 API를 생성한 다음 사용자정의 코드를 구현해야 합니다.

기본 커넥터 설정

REST 커넥터 API 마법사에서 처음 두 페이지를 완료하여 작동 커넥터를 생성할 수 있습니다.

을 누르고 개발, 사이드 메뉴에서 API를 차례로 선택합니다.
REST(생성할 첫번째 커넥터 API인 경우) 또는 새 커넥터를 누르고 드롭다운 목록에서 REST를 선택합니다.
다음을 제공하여 새 REST 커넥터 API를 식별합니다.
1. API 표시 이름: 커넥터 API 목록에 표시되는 이름입니다.
2. API 이름: 커넥터 API에 대한 고유 이름입니다.
  
  기본적으로 이 이름은 커넥터 API에 대한 리소스 이름으로 상대 기본 URI에 추가됩니다. API 이름 필드 아래에 기본 URI가 표시됩니다.
  
  이 커넥터 API의 새 버전 이외에 다른 커넥터 API는 동일한 리소스 이름을 가질 수 없습니다.
3. 간단한 설명: 이 설명은 이 API를 선택할 때 [커넥터] 페이지에 표시됩니다.
생성을 누릅니다.
REST 커넥터 API 대화상자의 [일반 사항] 페이지에서 시간 초과 값을 설정합니다.
- HTTP 읽기 시간 초과: 데이터 읽기를 기다리는 데 소요될 수 있는 최대 시간(밀리초)입니다. 값을 제공하지 않으면 기본값인 20초가 적용됩니다.
- HTTP 접속 시간 초과: 원격 URL에 접속하는 데 걸린 시간(밀리초)입니다. 값이 0mm이면 무한 시간 초과가 허용됩니다.
  
  HTTP 시간 초과 값은 40,000밀리초의 기본값인 Network_HttpRequestTimeout 정책보다 작아야 합니다.
  
  주:
  서비스 개발자 롤 외에도 모바일 클라우드 관리자 롤이 있는 경우 policies.properties 파일을 열어 [관리자] 뷰에서 현재 환경에 대한 네트워크 정책 값을 확인할 수 있습니다. 그렇지 않으면 Mobile Cloud 관리자에게 값을 요청하십시오.
기술자를 누르고 서비스에 대한 접속 정보를 입력합니다.

Swagger 기술자 URL을 제공하면 사용 가능한 리소스가 식별되고 표시되며 원하는 리소스를 선택할 수 있습니다.

주:
표준 인터넷 액세스 포트 80 및 443만 지원됩니다. 사용자정의 포트를 사용하여 서비스에 접속할 수 없습니다.
저장을 누릅니다.
(선택 사항) 테스트를 누르고 인증 인증서를 선택한 다음 서비스에 대한 테스트를 호출합니다.

여기서 다음과 같은 방법으로 커넥터를 추가로 구성할 수 있습니다.

[기술자] 페이지에서 기술자를 제공한 경우 리소스 페이지로 이동하여 노출된 리소스에 대한 메소드를 선택합니다.
규칙을 정의합니다.
보안 정책 설정.

커넥터 API 구성이 적합한지 확인하려면 게시하기 전에 커넥터 API 테스트 페이지뿐만 아니라 철저하게 테스트해야 합니다. 즉, 이 커넥터 API를 사용하는 커스텀 API(구현 포함)도 테스트해야 합니다. 기본적으로 커넥터 API를 게시할 준비가 된 경우 이를 호출하는 사용자정의 API도 게시할 준비가 되어 있어야 합니다.

규칙 설정

모바일 앱과 서비스 간의 상호 작용을 정의하는 규칙을 설정합니다. 규칙은 서비스의 리소스에 대한 모든 호출, 특정 프록시 경로에 대한 호출 및 특정 유형의 작업(동사)에 대한 호출에 대한 기본 매개변수 값을 추가할 수 있는 방법을 제공합니다. 이렇게 하면 URL 문자열의 일관된 구문을 적용할 수 있고, 사용자정의 코드 개발자가 이러한 값을 삽입할 필요가 없으며, 분석을 통해 다양한 호출을 추적할 수 있습니다.

하나 이상의 규칙을 생성할 수 있습니다. 각 규칙에는 Query 및 Header 유형의 매개변수가 하나 이상 있을 수 있습니다.

규칙이 적용되지 않으면 모든 호출이 프록시를 통해 기존 서비스로 전달됩니다.

커넥터가 아직 열려 있지 않은 경우 을 누르고 사이드 메뉴에서 개발, API를 차례로 선택합니다.
편집할 커넥터 API를 선택하고 열기를 누릅니다.
역할을 선택합니다.
새 규칙을 누릅니다.
매개변수 추가를 누르고 질의 또는 헤더 매개변수 유형을 선택하고 질의 또는 헤더 이름과 해당 값을 입력합니다.

주:

기본적으로 특정 헤더를 설정하는 규칙을 정의할 수 있지만 사용자정의 코드를 통해 직접 커넥터를 호출했거나 웹 브라우저 또는 모바일 앱과 같이 간접적으로 커넥터를 호출한 클라이언트가 이미 동일한 헤더를 설정한 경우 규칙이 적용되지 않습니다.

특히 요청 본문의 형식 설정은 일반적으로 REST 커넥터 규칙이 아닌 Content-Type 헤더를 사용하여 사용자정의 코드에서 수행됩니다. 마찬가지로, 응답 본문의 형식 설정도 REST 커넥터 규칙이 아닌 Accept 헤더를 사용하여 사용자정의 코드에서 수행됩니다.

규칙에 원하는 만큼 매개변수를 추가할 수 있지만 너무 많은 작업으로 규칙을 오버로드하지 않는 것이 좋습니다. 간단한 규칙 생성으로 문제를 쉽게 해결할 수 있습니다.
리소스를 확장하고 원격 URL을 편집하여 적용할 규칙에 대한 리소스를 제공합니다. 기본 URL 값은 기본 정보 설정 단계에서 입력한 값으로, 편집할 수 없습니다.
규칙을 원격 URL에 지정된 리소스 레벨에만 적용하려면 하위 레벨 리소스에 적용 안함을 선택합니다.
(선택 사항) 방금 정의한 규칙에 적용하지 않으려는 HTTP 메소드의 선택을 취소합니다. 기본적으로 모든 메소드가 선택됩니다.
(선택 사항) 새 규칙을 눌러 다른 규칙을 생성합니다.

주:

다른 규칙과 충돌하는 규칙을 정의하면 적용된 첫번째 규칙이 우선하며 충돌하는 규칙이 무시됩니다.

완료되면 저장, 다음(>) 순으로 눌러 커넥터 API 구성의 다음 단계로 이동합니다.

방금 정의한 규칙에 대한 설명은 기본 매개변수 섹션 바로 위의 규칙 배너에 표시됩니다. 예를 들어, 다음 값이 제공되었다고 가정해 보겠습니다.

원격 URL = https://maps.googleapis.com/maps/api/directions/json?origin=los+angeles&destination=seattle
로컬 URI = myMapAPI
다음 매개변수를 사용하는 규칙: Query:key:A3FAEAJ903022
GET 및 PUT HTTP 메소드

규칙 설명은 다음과 같습니다.

myMapAPI/directions에서 사용 가능한 GET ~ https://maps.googleapis.com/maps/api/directions/json?origin=los+angeles&destination=seattle의 경우 Query:key=A3FAEAJ903022를 포함합니다.

규칙을 생성하지 않은 경우 설명은 다음과 같습니다.

myMapAPI에서 https://maps.googleapis.com/maps/api/directions에 대한 모든 방법의 경우 기본 매개변수가 적용되지 않습니다.

이제 기존 서비스에 매핑되는 기본 URI가 있습니다. 예제 사용:

mobile/connector/myMapAPI/directions/json?origin=los+angeles&destination=seattle는 https://maps.googleapis.com/maps/api/directions/json?origin=los+angeles&destination=seattle에 매핑됩니다.

보안 정책 및 무효화 속성 구성

커넥터 API를 완성하기 전에 보안 처리 방법을 고려해야 합니다. 보안 정책 또는 권한 부여 헤더를 사용할 수 있습니다. 연결하려는 서비스의 인증 체계를 설명하는 보안 정책을 선택하는 것이 좋습니다.

모든 보안 정책에는 사용자가 구성할 수 있는 대체라는 등록 정보가 있습니다. 정책 구성 등록 정보를 대체할 이유 중 하나는 유지 관리해야 하는 정책 수를 제한하는 것입니다. 약간 다양한 구성으로 여러 정책을 만드는 대신 동일한 일반 정책을 사용하고 특정 값을 대체하여 요구 사항을 충족할 수 있습니다.

보안 정책을 선택하고 정책 우선 순위를 설정하려면 다음과 같이 하십시오.

커넥터가 아직 열려 있지 않은 경우 을 누르고 사이드 메뉴에서 개발, API를 차례로 선택합니다.
편집할 커넥터 API를 선택하고 열기를 누릅니다.
보안을 선택합니다.
사용 가능한 정책 목록에서 보안 정책을 선택하고 오른쪽 화살표를 눌러 선택된 정책 목록으로 이동합니다.
커넥터 API에 대해 단일 정책만 선택하십시오. 선택한 정책에 대한 설명이 목록 아래에 표시됩니다.
기본값을 사용하지 않으려면 선택한 정책에 우선 적용을 지정합니다(해당하는 경우).
등록 정보를 대체하려면 기본값 이외의 값을 입력하거나 선택합니다.
저장을 눌러 작업을 저장하거나 저장 후 닫기를 눌러 작업을 저장하고 REST 커넥터 API 마법사를 종료합니다.
다음 (>)을 눌러 다음 단계로 이동합니다.