카우치베이스 모바일

모바일 개발자: REST가 밤잠을 설치게 하나요?

RE프레젠테이션 State T일반적으로 "REST"로 알려진 랜서퍼는 웹을 통해 백엔드 데이터 서비스와 프로그래밍 방식으로 통신하기 위한 표준을 설명합니다.

REST API는 다음과 유사한 기본 URL 엔드포인트를 통해 HTTP 요청을 사용하여 POST(작성), GET(읽기), PUT(업데이트) 및 DELETE 데이터("CRUD 작업"이라고 함)를 처리하는 프로그래밍 인터페이스입니다. https://sample.com/api/products. 개발자는 엔드포인트에 대한 HTTP 요청을 통해 API와 상호 작용하는 앱을 빌드합니다.

REST API 엔드포인트는 개발자가 데이터 소스와 상호 작용할 수 있도록 노출되는 쿼리의 캡슐화라고 생각하면 됩니다. 복잡성이 추상화되어 있어 REST를 쉽게 사용할 수 있지만, API 작성자가 생각하고 노출한 쿼리만 대중이 사용할 수 있으며, 그 이상의 데이터를 조작하려면 프로그래밍이 필요하다는 점을 명심하세요.

단순성과 거의 모든 주요 소프트웨어 솔루션이 REST 액세스를 제공한다는 사실 때문에 데이터에 REST API를 활용하는 것이 웹 앱 개발의 인기 있는 접근 방식이 되었습니다.

애초에 REST가 필요한 이유는 무엇인가요?

REST API는 많은 앱, 특히 레코드 가져오기 및 업데이트에 대한 기본 요구 사항이 덜 복잡한 앱에 적합한 옵션입니다.

예를 들어, 소매업체의 '내 주변 위치'를 표시하는 앱은 사용자 위치 좌표를 다음과 같은 REST 엔드포인트로 전달할 수 있습니다. "https://sample.com/api/locations/?=___'를 입력하면 해당 위치의 지정된 반경 내에 있는 매장 주소를 반환합니다. 앱에서 '내 주변 위치' 기능에 필요한 모든 정보는 간단한 GET 호출합니다. 이러한 유형의 이유 때문에 엔티티에 대한 일반적인 액세스를 통해 앱 데이터 요구 사항을 충족할 수 있을 때 REST가 유용합니다.

그러나 사용자, 계정 또는 인벤토리와 같은 엔티티를 자주 수정하는 앱처럼 데이터 처리를 위해 더 많은 로직이 필요한 경우에는 많은 REST API만으로는 제공할 수 없는 세분화된 데이터 제어가 필요할 수 있습니다. 이로 인해 개발자는 앱에 필요한 정확한 데이터를 얻기 위해 REST의 한계를 고려하여 코드에서 데이터를 필터링하고 병합하는 등의 작업을 수행해야 하는 상황에 처하게 되며, 이는 시간이 더 걸리고 앱 효율성을 떨어뜨릴 수밖에 없습니다.

또한 앱이 모바일이기 때문에 데이터를 웹을 통해 REST API에 의존할 때 연결 문제도 해결해야 하는데, 이는 사소한 작업이 아닙니다.

여기에서 REST API의 문제점에 부딪히기 시작할 가능성이 높습니다...

REST 사용의 문제점

스키마 및 데이터 유형 유효성 검사 부족

모든 REST API는 노출하는 엔티티에 맞게 구축되므로 스키마 유효성 검사나 예상 데이터 유형에 대한 표준 프로토콜이 없습니다. 따라서 개발자는 이러한 세부 사항을 숙지하고 이를 해결해야 하며, 그렇지 않으면 앱 불안정성 및 충돌로 인한 결과를 감수해야 합니다.

예를 들어 ""를 사용하여 제품 목록 요청을 보낼 수 있습니다.GET /products'를 호출할 수 있지만 엔드포인트가 존재하는지 확인할 방법이 없습니다. 이전 버전의 API에서 사용할 수 있었던 엔드포인트를 최신 버전에서는 더 이상 사용할 수 없는 경우 특히 문제가 됩니다.

엔드포인트가 존재하더라도 엔드포인트가 반환하는 엔티티 세부 정보를 검증할 수 있는 방법이 없습니다. 예를 들어, 반환된 제품 목록의 특정 제품은 목록이 요청된 이후 다른 클라이언트에 의해 수정되거나 삭제되었을 수 있습니다.

각 엔드포인트가 구현된 방식에 따라 엔드포인트 간에 동일한 데이터에 대해서도 데이터 유형이 다를 수 있습니다. 예를 들어, 두 엔드포인트 요청은 모두 동일한 데이터를 반환하지만 약간의 차이가 있습니다:

요청 응답
GET /products/123 {
 가격: 10.95달러,
 통화: "USD"
}
GET /inventory/product/123 {
 가격: "10.95",
 통화: "USD"
}

이 예제에서 한 응답은 제품 가격을 더블로 반환하고 다른 응답은 제품 가격을 문자열로 반환합니다. 이러한 종류의 데이터 유형 불일치로 인해 앱이 불안정해지거나 충돌이 발생할 수 있습니다.

앞뒤로 데이터 변환

데이터 유형을 처리하려면 엔티티 데이터를 연결의 각 끝에서 기대하는 것으로 변환하는 끝없는 주기가 필요합니다. 예를 들어 앱이 REST API를 활용하는 경우 통신 흐름은 다음과 같습니다:

  1. 엔티티 데이터 모델 정의
  • 네이티브 코드에서 데이터 모델 정의
2. 데이터를 JSON으로 직렬화
  • 네이티브 객체를 JSON으로 변환
  • REST 엔드포인트가 기대하는 구조로 네이티브 데이터 엔티티의 형식 지정
3. HTTP를 통한 전송
  • 데이터를 JSON 문자열로 인코딩
  • JSON 문자열을 여러 부분으로 구성된 HTTP 양식 데이터로 인코딩하기
  • POST 요청 보내기
4. 백엔드에서 데이터 디코딩
  • POST 데이터 디코딩
  • JSON 문자열 디코딩
5. 데이터베이스에 대한 CRUD 작업
  • 데이터베이스 스토리지에 매핑되는 개체 만들기
  • 개체를 데이터베이스에서 예상하는 데이터 형식으로 변환

프로세스 흐름 전반에 걸쳐 데이터는 데이터베이스에서 애플리케이션으로, 그리고 다시 애플리케이션으로 전달되는 과정에서 몇 번이고 변환됩니다. 이 과정에서 상대방이 예상하지 못한 데이터가 포함된 요청이나 응답이 발생하여 불안정성 또는 충돌로 이어질 위험이 가장 높습니다. 그리고 이 문제는 스키마 유효성 검사가 부족하고 REST의 데이터 입력이 엄격하기 때문에 더욱 악화됩니다.

비즈니스 도메인 로직을 간단한 전송 모델로 변환하기

도메인 모델에 따라 개발하는 경우 제품 기능 요구 사항에 맞게 엔티티를 신중하고 의도적으로 설계하고 앱의 의도된 사용 사례의 비즈니스 로직을 따릅니다.

그러나 REST API를 활용하려면 엔티티에 대한 CRUD 작업 측면에서 신중하게 설계된 비즈니스 도메인을 다시 상상해야 합니다. 예를 들어 새 계정을 만드는 것과 같이 앱에서 단일 원자 작업으로 보이는 작업도 실제로는 REST API에 대한 일련의 여러 요청이 필요할 수 있습니다.

따라서 REST를 활용하려면 API에 맞게 모델을 래핑해야 하며, 이 과정에서 모델의 풍부함과 표현력을 잃는 경향이 있습니다.

본질적으로 신뢰할 수 없는 인터넷에 대처하기

목록의 첫 번째 오류는 분산 컴퓨팅의 오류 신뢰할 수 있는 네트워크. 이 목록을 작성한 Sun의 피터 도이치와 그의 동료들은 네트워크 연결에 과도하게 의존하는 앱에 대해 이렇게 말했습니다:

"소프트웨어 애플리케이션은 네트워킹 오류에 대한 오류 처리 기능이 거의 없이 작성됩니다. 네트워크가 중단되는 동안 이러한 애플리케이션은 응답 패킷을 멈추거나 무한 대기하여 메모리나 기타 리소스를 영구적으로 소모할 수 있습니다. 장애가 발생한 네트워크를 사용할 수 있게 되면 이러한 애플리케이션은 중단된 작업을 다시 시도하지 못하거나 (수동으로) 다시 시작해야 할 수도 있습니다."

모바일 앱을 자주 사용하고 출퇴근이나 여행 등 자주 위치를 변경하는 경우, 해당 앱에 영향을 미치는 인터넷 데드존으로 인한 불편함을 경험해 본 적이 있을 것입니다.

개발자에게 네트워크 가용성을 처리하는 방법은 앱 UX에 큰 영향을 미칩니다. 네트워크 문제로 인해 발생할 수 있는 잠재적인 장애 지점과 이를 해결하기 위한 다양한 방법이 있지만, 결론은 통신 로직과 오류 처리를 직접 구현해야 하므로 아무리 간단한 작업이라도 매우 복잡해질 수 있다는 것입니다. 

REST 엔드포인트에서 제품 목록을 요청하는 이 순서도를 고려하세요:

REST API endpoint flowchart for mobile apps

초기 앱 디자인에서는 요청을 발행하고, 응답을 받고, UI를 업데이트하는 작업이 REST를 통해 쉽게 이루어질 수 있습니다.

하지만 실제로는 각 요청마다 네트워크 가용성부터 시작하여 고려하고 처리해야 할 몇 가지 가능한 상태가 있습니다. 언뜻 보기에는 결정 포인트의 수가 관리하기 쉬워 보일 수 있지만, 장애로 이어지는 경로가 얼마나 많은지 생각해보면 이는 하나의 요청에 불과합니다.

이제 앱의 많은 작업에서 여러 종속 요청이 빠르게 연속적으로 발행되어야 하며, 각 요청은 플로차트의 의사 결정 지점을 통과해야 한다고 생각해 보세요. 이제 이 프로세스에 앱에서 일반적으로 발생하는 요청 수를 곱하면 충돌 가능성이 어떻게 기하급수적으로 높아지는지 쉽게 알 수 있습니다.

이 시나리오에서 일련의 종속 요청 중 마지막 요청이 실패하면 어떻게 복구할 수 있을까요? 성공할 때까지 요청을 다시 시도하나요? 일련의 이전 요청을 롤백하나요? 아니면 실패를 완전히 무시할까요? 네트워크 종속성으로 인해 발생할 수 있는 개발 과제의 종류입니다.

REST의 과제는 극복할 수 없는 것일까요? 아니요, 하지만......

유능한 개발자는 언제나 문제와 난관에 대한 해결 방법을 찾아낼 수 있습니다. 하지만 이렇게 하면 시간이 걸리고 앱 코드가 복잡해지며 앱의 운영 공간에 더 많은 리소스가 추가되어 속도가 느려지고 디바이스 배터리 수명이 더 많이 소모될 가능성이 높습니다. 진짜 문제는 "어떻게 문제를 해결할 것인가?"가 아니라 "어떤 대가를 치를 것인가?"입니다.

마이크로 서비스는 REST를 사용할 때 반복적인 작업을 자동화하는 데 도움이 될 수 있으며, API 작성자는 엔드포인트를 제공하기 위해 점점 더 창의적인 수단을 사용하고 있습니다. GET 매개변수 및 사용자 지정 POST JSON 페이로드와 요청을 대량으로 처리하는 엔드포인트를 지원합니다.

이러한 종류의 접근 방식은 REST를 사용할 때 몇 가지 골치 아픈 문제를 해결할 수 있지만 고충 사항 이 게시물에서 논의된 내용은 변함없이 유지됩니다:

    • 스키마 및 데이터 유형 유효성 검사 부족
    • 앞뒤로 데이터 변환
    • 비즈니스 도메인 로직을 단순한 전송 모델로 변환하기
    • 본질적으로 신뢰할 수 없는 인터넷에 대처하기

카우치베이스 모바일 데이터베이스 플랫폼

Couchbase Mobile은 데이터에 REST를 사용할 필요가 없도록 함으로써 REST API의 문제점을 해결합니다. 확장성과 복원력을 위한 클라우드 데이터베이스, 데이터 액세스를 위해 네트워크에 대한 종속성을 제거하는 온디바이스 데이터 처리용 임베디드 데이터베이스, 데이터 일관성을 위해 백엔드 데이터베이스와 다른 앱 클라이언트 간에 데이터 변경 사항을 자동으로 동기화하는 데이터 동기화 게이트웨이를 포함하는 모바일 및 IoT 앱을 위한 종합적인 데이터 저장 및 동기화 솔루션입니다.

Couchbase mobile data platforms

카우치베이스 모바일 스택에는 다음이 포함됩니다:

카우치베이스 카펠라 - SQL, 검색, 분석, 이벤트 지원을 제공하는 완전 관리형 클라우드 NoSQL 서비스형 데이터베이스(DBaaS)입니다.

카펠라 앱 서비스 - 모바일 및 엣지 앱의 양방향 동기화, 인증 및 액세스 제어를 위한 완전 관리형 서비스입니다.

카우치베이스 라이트 - SQL을 지원하는 임베디드 모바일 NoSQL 데이터베이스, 내장된 피어투피어 동기화, iOS(Swift, Obj-C), Android(Java, Kotlin), Windows(C#, .NET), 맞춤형 임베디드 기기/IoT(C-API) 등 광범위한 모바일 플랫폼 지원을 제공합니다.

Capella 앱 서비스는 스택의 바인딩 요소 역할을 하며 백엔드 Capella 데이터베이스, 엣지 데이터 센터, 엣지 디바이스의 Couchbase Lite 임베디드 앱 간에 웹소켓 기반 데이터 동기화를 제공합니다. 사용 웹소켓은 REST보다 우수한 데이터 전송 수단을 제공합니다. 대용량 데이터를 많이 사용하는 모바일 앱에 적합합니다. 앱 서비스를 사용하면 연결이 허용하는 한 데이터 변경 사항이 앱 에코시스템 전체에 즉시 자동으로 복제되며, 네트워크가 중단되는 동안에도 내장된 Couchbase Lite 데이터베이스 덕분에 앱이 계속 작동합니다.

카우치베이스 라이트 피어 투 피어 동기화

앱 서비스를 통해 클라우드와 엣지 간에 데이터를 동기화하는 것 외에도 Couchbase Lite는 로컬 및 개인 영역 네트워크를 통해 피어 투 피어 방식으로 데이터를 동기화할 수 있습니다.

Couchbase Lite 피어투피어 동기화 기능을 사용하면 중앙 제어 지점 없이 기기 간에 직접 데이터를 동기화할 수 있으므로, Couchbase Lite 임베디드 앱을 실행하는 기기 그룹이 클라우드 액세스나 인터넷 연결에 관계없이 서로 데이터를 공유할 수 있는 격리된 상태에서 협업할 수 있습니다. 인터넷 연결이 가능해지면 Couchbase Lite 클라이언트는 앱 서비스를 활용하여 클라우드에 동기화할 수 있습니다.

how to do peer-to-peer mobile sync

카우치베이스의 장점

Couchbase를 사용하면 클라우드 데이터베이스에서 모바일 장치에서 실행되는 앱으로 동일한 데이터 엔티티를 공유하고, 해당 데이터에 대해 간단한 표준 방식을 활용하여 CRUD 작업을 수행할 수 있습니다: SQL입니다. 데이터 처리가 코드에 내장되어 있으므로 더 이상 네트워크에 의존하여 액세스할 필요가 없으며 전송 계층, 데이터 계층, UI 간에 데이터를 주고받을 필요가 없습니다.

Couchbase를 사용하면 다음과 같은 이점이 있습니다:

오프라인 우선 기능 - 앱은 내장된 로컬 데이터베이스 덕분에 항상 작동하며, 네트워크에 연결되면 변경 사항이 클라우드 데이터베이스와 다른 앱 클라이언트에 자동으로 동기화됩니다.

더 쉬운 개발 - 원하는 프로그래밍 언어를 사용해 비즈니스 로직을 구성하고 데이터 엔티티로 작업하세요. 더 이상 커뮤니케이션 계층의 요구 사항을 충족하기 위해 비즈니스 도메인을 제한할 필요가 없으며, 끝없는 데이터 변환을 반복할 필요가 없습니다.

견고한 보안 - 카우치베이스 모바일은 인증, 역할 기반 액세스 제어, 미사용 시 AES 256 암호화, 유선에서의 TLS 1.2 암호화 기능을 제공합니다.

엔드투엔드 데이터 동기화 - 캐싱 기능을 구축하느라 시간을 낭비하지 말고 기성 데이터 동기화 솔루션을 사용하여 팀이 앱 프론트엔드를 최상의 상태로 만드는 데 집중할 수 있도록 하세요. Couchbase는 REST보다 훨씬 안정적이고 탄력적인 웹소켓을 사용하여 클라우드와 모바일 기기 간에, 심지어 여러 플랫폼에 걸쳐 데이터를 즉시 동기화합니다.

카우치베이스 모바일 무료 체험

카우치베이스 모바일을 사용하면 REST의 문제점을 제거하여 모바일 앱 개발을 간소화하고 네트워크 연결에 대한 의존성을 줄이며 앱의 전반적인 속도, 효율성 및 응답성을 개선할 수 있습니다.

REST를 사용하여 모바일 앱을 빌드하는 데 더 이상 시간을 낭비하지 말고, 더 쉬운 개발, 더 나은 성능, 더 빠른 응답성 및 오프라인 우선 기능을 위해 Couchbase를 시작하세요.

 

이 문서 공유하기
받은 편지함에서 카우치베이스 블로그 업데이트 받기
이 필드는 필수 입력 사항입니다.

작성자

게시자 카우치베이스 제품 마케팅

댓글 남기기

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

개발자 포털에서 NoSQL을 살펴보고, 리소스를 찾아보고, 튜토리얼을 시작하세요.

카펠라 무료 사용

클릭 몇 번으로 Couchbase를 직접 체험해 보세요. Capella DBaaS는 가장 쉽고 빠르게 시작할 수 있는 방법입니다.

연락하기

카우치베이스 제품에 대해 자세히 알고 싶으신가요? 저희가 도와드리겠습니다.