마주치는 대부분의 API는 REST(Representational State Transfer)라고 알려진 일련의 규칙을 따릅니다. 이 블로그에서는 REST API와 그 작동 방식에 초점을 맞출 것입니다. Mendix.

이제 무엇을 표현해야 할까?

간단히 말해서 REST는 데이터 전송을 제어하는 ​​"규칙" 또는 프로토콜 집합입니다. API가 이러한 규칙을 따를 때, 우리는 그것을 RESTful API라고 부릅니다. REST라는 용어는 Roy Fielding이 2000년에 발표한 박사 학위 논문 "네트워크 기반 소프트웨어 아키텍처의 아키텍처 스타일과 설계"에서 만들어냈습니다. 걱정하지 마세요, RESTful API를 이해하기 위해 그의 논문을 읽을 필요는 없습니다. 그 이후로 RESTful API는 오늘날 웹에서 시스템 간에 데이터를 전송하는 사실상의 방법이 되었습니다.

그렇다면 이 규칙은 무엇일까요? 간단히 말해서, 규칙은 API마다 다르지만, 보편적으로 수용되는 표준은 API를 RESTful하게 만드는 데 도움이 됩니다.

• 엔터티 또는 리소스를 고유한 URI로 구성합니다.. URI는 Uniform Resource Identifier의 약자입니다. URI는 네트워크 위치와 액세스하려는 리소스의 두 부분으로 구성됩니다. 네트워크 위치는 일반적으로 웹사이트 URL이고 리소스는 웹사이트가 보유한 데이터 표입니다.
• 그것은 무국적자. 즉, 필요한 올바른 세부 정보를 제공하는 한 어떤 순서로든 모든 API를 호출할 수 있습니다. 또한 서버가 클라이언트의 세션 데이터를 저장할 필요가 없으므로 고성능 앱에도 적합합니다.
• 그것은 사용 HTTP 메소드. RESTful API는 다양한 유형 또는 HTTP 메서드로 제공됩니다. 데이터와 상호 작용하려는 방식에 따라 사용할 메서드 유형이 정의됩니다. (바로 데이터를 검색합니다. POST 데이터를 생성합니다. 반점 데이터를 업데이트합니다. 삭제 데이터를 파괴하거나 지웁니다. 그 외에도 많은 것들이 있지만 이것이 *주요* 것들입니다.
• 데이터 페이로드는 다음을 사용하여 포맷됩니다. JSON or XML. 대부분의 REST API는 데이터를 JSON 또는 XML 페이로드로 포맷합니다. 다른 포맷으로는 HTML, 마크업, 이미지, 문서가 있습니다(API가 여러 페이로드 포맷을 지원하는 경우 "수락” 헤더)

REST의 역사와 표준에 대해 자세히 알고 싶다면 다음에서 자세히 읽어보세요. 위키 백과.

소비 VS 게시

API 개발에서는 다른 사람이 사용할 수 있도록 API를 게시하는 것과 직접 사용하는 것에는 차이가 있습니다. Mendix 둘 다 할 수 있게 해주고, 다른 시스템의 REST API를 사용하고, 동일한 앱 내에서 자체 API를 게시할 수 있습니다. 일부 앱은 아키텍처의 일부인 자체 노출 서비스를 호출하기도 합니다.

이전 글이 소비에 관한 것이었기 때문에 이 블로그에서는 REST API 게시에 대해 이야기하겠습니다. in Mendix.

여기서 언급할 가치가 있습니다. Mendix OData API도 지원합니다 특정 시나리오에서 많은 이점을 제공하고 skip, filter, order by, select와 같은 강력한 필터가 있는 out of the box입니다. 그러나 이 글은 표준 REST API에 대한 것이고 다음 블로그에서 OData를 다루고 싶습니다. 광범위한 주제이고 자세히 다루고 싶기 때문입니다.

노출된 REST 서비스 생성

무언가를 배우는 가장 좋은 방법은 직접 해보는 것입니다. 따라서 이 섹션은 REST API를 게시하는 방법에 대한 실용적인 가이드가 될 것입니다. 간단한 사용 사례를 다루기 위해 간단한 API 컬렉션을 만드는 방법을 보여드리겠습니다. 제가 이미 만든 간단한 영화 카탈로그 앱과 상호 작용하기 위한 것입니다.

보시다시피 앱은 영화 제목 목록과 해당 영화의 IMDB 페이지로 연결되는 링크를 표시하는 홈페이지일 뿐입니다. 상호작용할 수 있는 무언가를 만들기 위해 데이터를 채워보겠습니다.

도메인 모델에서 엔터티의 데이터를 노출하려면 엔터티를 선택하고 마우스 오른쪽 버튼을 클릭한 다음 "REST 리소스로 노출"을 선택하면 됩니다.

프로젝트에서 서비스를 요청하지만 프로젝트의 모든 모듈에서 새 서비스를 만들도록 선택할 수 있습니다. 이 예에서 저는 Movielist를 호출했습니다.

그런 다음 키 속성을 결정해야 합니다. 이는 특정 데이터와 상호 작용하고 키, Patch 및 Delete를 통한 GET과 같은 HTTP 메서드를 사용하려는 경우에만 필요합니다.

OK를 클릭하면 Studio Pro가 나머지 작업을 처리하고 엔터티를 REST API로 제공하는 데 필요한 모든 매핑과 로직을 생성합니다.

이 시점에서 프로젝트를 로컬에서 실행하고 Postman이나 다른 API 테스트 소프트웨어를 통해 API와 상호 작용할 수 있습니다.

앱이 실행되면 새로운 서비스에 액세스할 수 있게 되며(로컬 개발 머신에서), {Your_app_URL/api-doc/에서 앱의 모든 게시된 API 요약을 볼 수 있습니다. 제 예에서는 다음과 같습니다. https://localhost:8080/api-doc/

Postman으로 API 테스트하기

앱이 실행 중이고 다음이 있으면 우편 집배원 동일한 컴퓨터에 설치하고 열면 Studio Pro에서 생성된 GET 메서드의 세부 정보를 두 번 클릭하여 열 수 있습니다.

예시 위치라는 필드가 있다는 것을 알 수 있을 것입니다. 이것은 앱의 로컬 복사본의 로컬 호스트와 런타임 포트를 사용하기 때문에 예시입니다. 이것은 Postman에서 잘 작동하므로 이 URI를 복사하여 사용할 수 있습니다.

Postman에서 새 요청을 만들고 요청 URI 필드에 URI를 붙여넣은 다음 보내기를 클릭합니다.

아래 창에서 XML로 포맷된 결과가 반환되는 것을 볼 수 있습니다. 또한 200 OK인 상태 필드도 수신합니다. 이는 요청이 성공적으로 처리되었음을 의미합니다.

직접 해보기

쉽게 들리지만, 서비스가 하는 일에 대해 더 많은 제어권을 원한다면 어떨까요? 글쎄요, Studio Pro에 의존해서 생성해 줄 필요는 없습니다. API를 완전히 처음부터 만들고 모든 세부 사항을 원하는 대로 지시할 수도 있습니다.

위에서 언급했듯이 우리가 만든 자동 생성 서비스는 XML로 데이터를 반환합니다. 이는 대부분의 시나리오에서 괜찮지만 대신 JSON으로 결과를 반환하고 싶다면 어떨까요?

이 엔드포인트에 대한 로직을 처리하는 마이크로플로를 열 수 있습니다. 이 경우 "Movies_Get_All"이라고 합니다.

지금 마이크로플로는 단순히 모든 레코드를 검색하여 반환합니다. XML로의 변환은 "Movies_Export"라는 REST 서비스에 연결된 내보내기 매핑에 의해 처리됩니다.

반환 유형을 변경하려면 JSON으로 할 수 있습니다 “Accept” 헤더를 사용하세요 값과 함께 "애플리케이션/JSON” 위에서 언급했듯이요.

앱을 다시 실행하지 않고 "Accept" — "Application/JSON" 헤더를 추가하는 것 외에는 다른 세부 정보를 변경하지 않고 Postman에서 다시 테스트합니다.

모든 것이 성공하면 JSON으로 페이로드를 받게 됩니다. 서비스의 응답 시간이 거의 400ms(밀리초) 감소한 것을 알 수 있습니다. 이는 API 응답 시간이 상당히 개선된 것입니다. JSON은 특별히 데이터 전송을 위해 설계되었기 때문입니다. 다음과 같은 최적화 모범 사례를 사용하여 서비스를 미세 조정하여 응답 시간을 더욱 빠르게 할 수 있습니다. 인덱스 적용 데이터베이스 검색 시간을 단축합니다.

처음부터 구축

한 단계 더 나아가 API의 모든 구성 요소를 처음부터 만들 수 있습니다. 이제 이 노출된 서비스에 대한 새 리소스를 빌드하여 시도해 볼 수 있으며, 이는 특별히 사용자를 맞이할 것입니다.

시작하려면 노출된 서비스의 리소스 아래에 있는 "추가"를 클릭하고 새 리소스에 이름을 지정합니다. 저는 "hellothere"라고 이름 지은 후 "확인"을 클릭합니다.

다음으로, 이 리소스에 대한 작업을 만들어야 합니다. 새 리소스를 선택하고 "작업"에서 "추가"를 클릭합니다.

Method를 GET으로 두고 Operation 경로를 변경하지 않을 것입니다. 로직을 처리할 마이크로플로만 제공하면 됩니다. "Select"를 클릭하고, 플로우를 원하는 위치를 선택한 다음 "new"를 클릭합니다. 저는 자동 생성된 마이크로플로 이름인 "GetHelloThere"를 사용했습니다.

흐름을 열고 마이크로흐름 엔드포인트를 두 번 클릭하여 데이터 페이로드를 사용자 지정 JSON 문자열로 지정할 수 있습니다.

'{''인사말'':''https://www.youtube.com/watch?v=eaEMSKzqGAg”}'

따옴표를 주목하세요 인사말과 Youtube 링크의 JSON 키-값 쌍을 중심으로. 이것은 큰따옴표가 아니라 열고 닫는 두 개의 작은따옴표입니다.. 이것은 Studio Pro가 일반적으로 따옴표를 문자열 변수의 끊김으로 해석하기 때문에 문자열을 이스케이프하는 것입니다. 이것은 Studio Pro가 응답에 인용문을 포함하도록 지시합니다..

이제 우리는 앱을 다시 실행하고 Postman에서 새 서비스를 테스트할 수 있으며 모든 것이 잘된다면 사용자 지정 페이로드가 다음과 함께 반환되는 것을 볼 수 있습니다. 200 OK 상태.

모든 설정!

이제 REST API를 직접 만드는 데 필요한 모든 것을 알게 되었습니다. Mendix. 서비스에 보안, 인증 또는 사용자 지정 헤더를 추가하는 것과 같이 더 자세히 알아보려면 academy.mendix.com으로 이동하여 학습하세요. OData의 세계로 뛰어드는 다음 작품을 기대하세요.