ios Archives - How IT

모바일 측면에서 새로운 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는 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의 발굴도 포함)!

How IT