Faconvenade REST 서비스에 대한 사용자정의 API 구현
모바일 애플리케이션을 개발하는 경우 일반적으로 사용자 인터페이스 계층에서 시작한 다음 REST 웹 서비스를 사용하여 애플리케이션을 다른 애플리케이션과 연결합니다. 이 접근법은 소규모 또는 단순한 애플리케이션에 적합합니다. 응용 프로그램이 클수록 여러 백엔드 서비스에 접속할 때 실수로 성능 및 보안 문제를 일으킬 수 있습니다.
외부 백엔드 서비스와 사용자 인터페이스 간에 가끔 API 층을 구축하여 가능하면 백엔드 서비스에 대한 호출 수를 줄이는 것이 가장 좋습니다. 예를 들어, 모바일 응용 프로그램은 다른 REST 서비스에 대한 호출을 처리하는 faletter API 계층에 대한 단일 호출을 실행하고 모바일 응용 프로그램에 대한 단일 응답으로 모든 수신 데이터를 통합할 수 있습니다.
전체 사용자정의 API 생성
Oracle Mobile Hub 를 사용하여 완전한 사용자정의 API를 생성합니다.
을 누르고 측면 메뉴에서 개발, api 순으로 선택합니다. API가 이미 생성된 경우(초안 또는 게시됨 상태인지 여부) API 목록이 표시됩니다. 사용자정의 API가 존재하지 않으면 새 API 단추가 있는 페이지가 표시됩니다. 이미 생성한 API를 누르거나 새 API를 눌러 시작합니다.
끝점 정의
리소스를 생성하여 API의 끝점을 정의합니다. 리소스는 API의 물리적 리소스입니다. 유형, 즉 일부 데이터가 연관되어 있고 다른 리소스와 관련된 관계를 가지며 이를 처리하는 하나 이상의 메소드를 포함합니다. 리소스는 이미지, 텍스트 파일, 다른 리소스의 모음, 논리적 트랜잭션, 프로시저 등의 거의 모든 것일 수 있습니다.
리소스에 대한 메소드를 생성할 때 메소드 링크 아래에 해당 메소드에 대한 기호가 나타납니다. 리소스 정의를 확인해야 하는 경우 리소스에 대해 정의된 메소드를 즉시 확인할 수 있습니다. 아이콘을 누르면 해당 메소드 정의로 직접 이동합니다.
압축 모드 (새 리소스 오른쪽에 있음) 로 전환하여 더 빨리 리소스를 찾을 수 있습니다. 그러면 리소스 설명, 리소스 유형 및 경로가 숨겨집니다.
리소스에 메소드 추가
메소드 는 리소스에 대해 수행할 수 있는 작업입니다. [메소드] 페이지에는 한 번에 하나의 메소드가 표시됩니다. 메소드가 두 개 이상 정의된 후에는 페이지 상단에 있는 메소드에 대한 아이콘을 눌러 해당 세부정보를 볼 수 있습니다.
리소스에 대한 메소드를 정의한 후 해당 메소드에 대한 요청과 응답을 정의할 수 있습니다.
메소드에 대한 요청 정의
이제 방법을 선택하고 연결하려는 서비스에 대해 원하는 요청을 정의합니다. 예를 들어, POST
메소드를 선택한 경우 이제 생성할 항목을 정의할 수 있습니다. 이렇게 하려면 서비스에 전송할 데이터에 대한 설명이 포함된 매개변수 및 요청 본문을 추가합니다.
- 요청 을 눌러 요청을 정의합니다.
- 매개변수 추가 를 누르고 매개변수 유형 (질의 또는 헤더) 을 선택합니다. 메소드에 매개변수가 필요한 경우 필수 를 선택합니다.
- 선택한 메소드에 따라 매체 유형 추가 를 누르고 메소드 본문을 정의합니다. 본문에는 서버로 전송할 데이터가 포함됩니다. 예를 들어,
POST
메소드를 정의하는 경우 새 고객 목록 또는 서비스 요청과 같이 생성 중인 항목을 정의해야 합니다.GET
메소드를 정의하는 경우 매체 유형을 지정할 필요가 없도록 메소드 본문을 전송할 필요가 없습니다. - 매체 유형을 더 추가하려면 매체 유형 추가 를 누릅니다. 메소드를 원하지 않을 경우 배너에서 X 를 눌러 삭제합니다.
메소드에 대한 응답 정의
요청에 따라 응답이 필요할 수도 있고 필요하지 않을 수도 있습니다. 응답은 서비스에서 결과를 반환하는 프로세스를 설명합니다. 요청한 데이터가 반환되었는지 확인하는 응답을 정의하거나 요청이 수신되었는지 여부를 확인하는 응답이 필요할 수 있습니다. 응답 정의는 요청 정의와 유사합니다. 주된 차이점은 접속 결과를 알려 주는 상태 코드를 선택해야 한다는 것입니다.
audits
리소스의 POST
메소드에 대한 응답이 새 리소스가 성공적으로 생성되었음을 나타내는 상태 코드 201로 생성되었음을 보여줍니다. 이 예에서는 application/json
의 반환 응답 형식, 추가된 Location
헤더 및 mock 데이터가 포함된 메시지 본문도 보여 줍니다.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를 식별합니다.
-
API 표시 이름: 커넥터 API 목록에 표시되는 이름입니다.
-
API 이름: 커넥터 API에 대한 고유 이름입니다.
기본적으로 이 이름은 상대 기본 URI에 커넥터 API의 리소스 이름으로 추가됩니다. API 이름 필드 아래에 기본 URI를 볼 수 있습니다.
이 커넥터 API의 새 버전이 아닌 다른 커넥터 API는 동일한 리소스 이름을 가질 수 없습니다.
-
간단한 설명: 이 API가 선택된 경우 이 설명이 [커넥터] 페이지에 표시됩니다.
-
-
생성을 누릅니다.
-
[REST 커넥터 API] 대화상자의 [일반 사항] 페이지에서 시간 초과 값을 설정합니다.
-
HTTP 읽기 시간 초과: 데이터 읽기 대기에 소비할 수 있는 최대 시간 (밀리초) 입니다. 값을 제공하지 않을 경우 기본값인 20초가 적용됩니다.
-
HTTP 접속 시간 초과: 원격 URL에 접속하는 데 걸린 시간 (밀리초) 입니다. 0mms 값은 시간 초과가 무제한으로 허용됨을 의미합니다.
HTTP 시간 초과 값은 기본값인 40,000밀리초가 포함된
Network_HttpRequestTimeout
정책보다 작아야 합니다.주:
서비스 개발자 롤 외에도 모바일 클라우드 관리자 롤이 있으면policies.properties
파일을 열어 관리자 뷰에서 현재 환경에 대한 네트워크 정책 값을 확인할 수 있습니다. 그렇지 않으면 Mobile Cloud 관리자에게 해당 값을 문의하십시오.
-
-
기술자 를 누르고 서비스에 대한 접속 정보를 입력합니다.
Swagger 기술자 URL을 제공할 경우 사용 가능한 리소스가 식별되고 표시되며 원하는 리소스를 선택할 수 있습니다.
주:
표준 인터넷 액세스 포트 80 및 443만 지원됩니다. 사용자정의 포트를 사용하여 서비스에 접속할 수 없습니다. -
저장을 누릅니다.
-
(선택사항) 테스트 를 누르고 인증 인증서를 선택한 다음 서비스에 대한 호출을 테스트합니다.
여기서 다음 방법으로 커넥터를 추가로 구성할 수 있습니다.
-
(기술자 페이지에서 기술자를 제공한 경우) 리소스 페이지로 이동하여 노출된 리소스에 대한 메소드를 선택합니다.
-
규칙을 정의합니다.
-
보안 정책을 설정합니다.
커넥터 API 구성이 적합한지 확인하려면 게시 전에 [커넥터 API 테스트] 페이지에서만 테스트합니다. 즉, 이 커넥터 API를 사용하는 사용자 정의 API (구현 포함) 도 테스트해야 합니다. 기본적으로 커넥터 API를 게시할 준비가 된 경우 이 API를 호출하는 사용자정의 API를 게시할 준비가 되어야 합니다.
규칙 설정
규칙을 설정하여 모바일 앱과 서비스 간의 상호 작용을 정의합니다. 규칙을 사용하면 서비스의 모든 리소스에 대한 기본 매개변수 값, 특정 프록시 경로에 대한 호출 및 특정 작업 유형 (동사) 에 대한 호출을 추가할 수 있습니다. 이를 통해 URL 문자열의 일관성 있는 구문을 적용하고 사용자정의 코드 개발자가 이러한 값을 삽입하지 않고도 사용자정의 코드 개발자를 저장하므로 분석을 통해 여러 호출을 추적할 수 있습니다.
규칙을 하나 이상 생성할 수 있습니다. 각 규칙은 Query
및 Header
유형의 매개변수를 하나 이상 포함할 수 있습니다.
규칙이 적용되지 않으면 모든 호출이 프록시를 통해 기존 서비스로 전달됩니다.
방금 정의한 규칙에 대한 설명은 [기본 매개변수 ] 섹션 바로 위의 규칙 배너에 표시됩니다. 예를 들어 다음 값이 제공되었다고 가정합니다.
-
원격 URL =
https://maps.googleapis.com/maps/api/directions
/json?origin=los+angeles&destination=seattle
-
로컬 URI =
myMapAPI
-
다음 매개변수를 사용하는 규칙:
Query:key:A3FAEAJ903022
-
GET
및PUT
HTTP 메소드
규칙 설명은 다음과 같이 표시됩니다.
GET
- https://maps.googleapis.com/maps/api/directions/json?origin=los+angeles&destination=seattle
의 경우 myMapAPI/directions
, 포함 Query:key=A3FAEAJ903022
에서 제공합니다.
생성된 규칙이 없으면 설명을 읽어 들입니다.
myMapAPI
에서 사용 가능한 모든 METHODS 에서 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
에 매핑됩니다.
보안 정책 구성 및 우선 적용 속성
모든 보안 정책에는 우선 적용이라는 속성이 있으며, 이 속성은 구성할 수 있습니다. 정책 구성 속성을 무효화하는 이유 중 하나는 약간 다른 구성으로 여러 정책을 생성하는 대신 동일한 일반 정책을 사용하고 요구 사항을 충족할 특정 값을 무효화할 수 있도록 유지 관리해야 하는 정책 수를 제한하는 것입니다.
보안 정책을 선택하고 정책 무효화를 설정하려면 다음과 같이 하십시오.