Rest API-모바일 전용 과제

모바일 측면에서 새로운 iOS 앱 프로젝트를 진행하고 있습니다. 일부 아키텍처 변경이 일어나고 있으며 우리가 빌드하는 앱과 웹 사이트와 같은 다른 클라이언트가 사용할 사용자 정의 빌드 개인 API에 의존해야합니다.

설계중인 API는 HTTP 동사에 매핑 된 Rest 스타일의 리소스 중심 URI 및 CRUD 작업을 따릅니다. 같은 것들:

GET www.example.com/books
DELETE www.example.com/books/482094
POST www.example.com/users/6793

문제는이 스타일로 인해 종종 모바일 클라이언트가 단일 앱 화면을로드하거나 단일 사용자 UI 작업을 관리하기 위해 많은 요청을 수행해야한다는 것입니다. 이로 인해 필요한 모든 것이 확보 될 때까지 앱이 8 초 동안 로딩 모드에있게됩니다. 느리고 응답이없는 앱입니다.

모바일 클라이언트는 연결과 관련하여 심각한 제한이 있으므로 이상적으로는 다음과 같은 규칙을 따라야합니다.

1 화면 == 1 API 호출

1 저장 == 1 API 호출.

이로 인해 REST 설계 원칙을 따르는 충돌 과정이 발생하는 많은 상황이 있습니다. 예를 들면 다음과 같습니다.

앱이 하루 동안 오프라인 상태 였고 4 개의 백엔드 데이터베이스 테이블과 동기화해야한다고 가정 해 보겠습니다. www.example.com/sync_everything?since=2015-07-24
사용자가 할 일 목록에 작업을 표시하는 등 사용자가 많은 개체를 편집 할 수있는 화면이 있다고 가정합니다. 편집마다 하나의 API 호출이 아닌 단일 배치 API 호출에서 모든 작업 레코드를 편집 할 수있는 방법이 있어야합니다.
ORDER, SALESMEN 및 PRODUCT db 테이블의 정보를 혼합하는 화면이 있다고 가정하면 세 번이 아닌 한 번의 호출로 해당 데이터를 가져와야합니다.

위험은 우리가 가진 가장 편안한 API와 가장 쓸모없는 응답없는 모바일 앱으로 끝날 수 있다는 것입니다.

문제는 내가 거기에 새로운 계약자이고 내가 필요로하는 것은 그 요점을 만드는 데 도움이되는 것, 존경받는 출처의 기사 또는 이와 비슷한 것입니다. 모바일 클라이언트의 REST 스타일을 타협하는 주요 업체 (예 : 복합 집계 API 엔드 포인트 사용)

또는이 일반적인 문제에 대한 해결책. 감사!

— 미카엘
소스

"API가 REST 스타일을 유지하면서 같은 유형 또는 다른 유형의 개체 및 포함 된 개체 컬렉션을 어떻게 제공 할 수 있을까요?" 질문을 이해하고 있습니까?

— joshp

일반적인 대답은 각 REST 호출이 다양한 선택적 매개 변수를 가져 와서 유연하면서도 비교적 직관적이어야한다는 것입니다. 동기화 사례는 항상 까다로울 수 있지만 일반 페이지의 경우 일반적으로 같은 유형의 여러 통화 , 즉 모든 GET을보고 있습니까?

— Ixrec

문제가 병렬 요청이 없을 때 API를 조정하는 것이 잘못된 해결책이라고 생각 합니다 . 8 개의 작은 요청은 서로를 기다릴 필요가없는 하나의 큰 요청보다 크게 나쁘지 않습니다. HTTP / 2로 전환 할 수 있습니까? 아니면 적어도 HTTP / 1.1 파이프 라이닝을 사용합니까?

— amon

참조 : REST 웹 서비스에서 일괄 작업을 처리하기위한 패턴? . 핵심은 충돌없이 함께 일괄 처리 할 수있는 명령 종류 (및 전제 조건)를 식별 한 다음 일괄 처리 된 순서의 JSON 표현을 만든 다음 전송하는 것입니다. 캐시 가능성 인 REST 의 주요 매력을 잃지 만 캐시 가능성은 모든 종류의 애플리케이션과 항상 관련이있는 것은 아닙니다. 논리적 종속성이있는 경우 일괄 처리 / 동시성을 적용 할 수 없습니다.

— rwong

중개자가 순서대로 여러 작업을 수행해야하는 상황에 대한 비유는 앞의 각 작업에 사소한 논리적 종속성이있는 "저장 프로 시저"와 유사하며 데이터베이스 대신 해당 중개자에서 실행됩니다. 그 아래, 중개인은 단일 "저장 프로 시저"호출을 필요한만큼 많은 RESTful 요청으로 변환 할 수 있지만 중개인의 구현 세부 사항입니다.

— rwong

설계중인 API는 HTTP 동사에 매핑 된 Rest 스타일의 리소스 중심 URI 및 CRUD 작업을 따릅니다.

이것이 바로 당신의 문제입니다.

데이터베이스의 모델로 리소스를 제한했습니다. 따라서 서버에 데이터베이스에 표시되지 않은 리소스 개념이 없으므로 이러한 모든 리소스를로드하는 데 시간이 오래 걸립니다.

예를 들어

www.example.com/books/482094
www.example.com/books/582045
www.example.com/books/427454
www.example.com/books/319343

내 라이브러리를 얻으려면 모두로드해야합니다.

이것은 RESTful 디자인에 문제가 아니며 실제로 REST 안티 패턴입니다. REST에는 리소스가 데이터베이스 모델을 포함하여 시스템의 다른 항목과 일대일로 매핑되어야한다고 말하는 것은 전혀 없습니다.

해결책은로드하려는 것과 더 일치하는 더 많은 리소스를 만드는 것입니다. 항상 5 개의 리소스가 함께 있으면 5 개의 리소스에 대한 정보가 포함 된 새 리소스를 만듭니다.

당신이해야 할 것은 이것과 같습니다

www.example.com/users/334/my_library

해당 사용자에 대한 모든 책을로드합니다. "my_library"는 데이터베이스의 모델이 아니지만 리소스입니다. 서버는 데이터베이스의 모델을 기반으로 작성하지만 일대일 맵핑이 없으며 서버는 DB 모델을 변경하지 않고이 자원을 유연하게 작성할 수 있습니다.

당신은 또한

www.example.com/users/334/favioured_books
www.example.com/users/334/books_ordered_last_week
www.example.com/users/334/wishlist

데이터베이스 또는 도메인 공간에 모델로 존재하지 않아도됩니다.

Rails와 같은 프레임 워크는 사람들에게 데이터베이스 행과 일대일로 다시 매핑되는 도메인 공간의 모델에 일대일 방식으로 리소스를 매핑하도록 사람들에게 가르쳤 기 때문에 이것이 잘못되었다는 오해가 널리 퍼져 있습니다. 이것은 필요하지 않으며 권장되지 않습니다.

리소스는 다양하고 저렴하며 가벼워 야 합니다. 작성하기 쉬워야하며 도메인 모델에서 추상화되어야합니다. 새로운 것이 필요하다면 새로 만드십시오. 이를 수행하는 데 문제점이있는 경우 이는 프레임 워크 결함이며 REST 결함이 아닙니다.

물론 이것의 큰 경고는 프레임 워크가 이것을 할 수 있는지 여부입니다. Rails와 Django와 같은 프레임 워크는 "시간을 절약"하기 위해 일대일로 매핑하는 과정을 거쳤습니다. 그러나 이는 RESTful 디자인이 아니라 프레임 워크의 결함입니다.

Jim Webber가 이것에 대해 더 자세히 논의하고 있습니다 (Rails의 발굴도 포함)!

https://yow.eventer.com/yow-2011-1004/domain-driven-design-for-restful-systems-by-jim-webber-1047

— 코맥 멀홀
소스

이것은 매우 흥미롭고 이것에 완전히 동의하지만 슬프게도 API를 수행하는 사람이 아니며 API에 영향을 줄 수있는 방법이 거의 없습니다. 많은 사람들이이 "반 패턴"을 여러 가지 이유로 사용할 것입니다 (많은 이유로 프레임 워크 제한이 하나임). 데이터베이스에 대해 명확하게 생각하기 위해 URI 정의 만 사용합니다. API 엔드 포인트는 DB를 시각화하는 또 다른 방법 일뿐입니다. 또한 경우에 따라 설명한 것과 같은 리소스를 생성하는 것이 개체가 실제로 다르기 때문에 어렵 기 때문에 이름을 지정하면 매우 모호한 용어로 이어질 수 있습니다.

— MikaelW

효율성 측면에서 문제로 돌아 가기 위해 모바일 화면이 매우 느리고 (이러한 경우에만) 복합 호출이 가능하지만 API를 감싸는 구성 요소에 앉아 있음에 동의했습니다 ( API 자체가 아니라), 모바일 클라이언트에서만 사용되며 핵심 API 인 핵심 도메인의 일부로 간주되지 않습니다.

— MikaelW

@MikaelW, 당신이 맞아요. Cormac이 말한 것은 이상적인 시나리오이지만 때로는 많은 다른 시스템 (데스크톱, 모바일, 웹, 예약 된 작업, 레거시 시스템 등)에 참여해야하는 API로 작업하고 있습니다. 이러한 종류의 API는 가능한 한 많은 가능성에 참여할 수있는 리소스를 제공하지만 한 소비자의 특정 성능 요구 사항에 모두 대응할 수는없는 유연한 유연성이 필요합니다. 이 경우 많은 선택의 여지가 없습니다 ...

— Dherik