클라이언트 / 서버 분리 제약사항
서로 커뮤니케이션하는 클라이언트와 서버, 가령 모바일 어플리케이션의 동작 방식과 API를 제공한는 서버의 동작 방식에 대해 분리해서 생각해야 한다
- 작업 방식에 집중하면 인터페이스가 복잡해진다.
- API 사용자의 관점과 컨슈머 소프트웨어의 입장으로 API를 디자인하자.
- API의 실제 목표를 정하자.
스테이트리스 제약사항
리퀘스트를 처리하는데 필요한 모든 정보는 상호작용을 할 때, 오직 서버만을 알고 있어야 한다. 서버는 리퀘스트를 처리하는데 필요한 클라이언트의 그 어떤 컨텍스트도 서버의 세션에 담지 않는다.
🤦♀️보내는 계좌의 목록 전송(클라이언트)
-> 서버측에서 세션에 저장(서버)
-> 저장되어있던 계좌를 이용하여 기능 구현(서버)
-> 해당 정보를 들고 있는 특정 인스터스만이 리퀘스트를 처리할 수 있다.
💁♀️서버와 리퀘스트 사이에 (세션 등을 통해) 중간에 저장하는 컨텍스트가 존재하지 않아야 한다.
-> API 목표를 독립적으로 사용할 수 있게 해주고, 해당 API의 재사용성을 높인다.
- 각 목표가 직관적인 상호작용을 제공하는지 확인한다.
- 목표의 호출에서 입력과 출력이 한결 같은지 확인한다.
- 가능한 경우 기존 목표에 데이터를 추가하여 오류를 방지하여 새로운 목표를 만든다.
- 연쇄되어있는 목표는 스테이트리스 해야한다.
- 에러 피드백은 반드시 이해하고 문제를 조치하는데 충분한 요소들을 제공해야 한다.
- 성공 피드백은 반드시 무엇이 완료되었는지 설명해 주어야 한다.
캐시 가능성 제약사항
리퀘스트에 대한 리스폰스는 저장 가능 여부(클라이언트가 동일한 요청을 다시 하지 않고 재사용할 수 있도록)및 기간을 표시해야 한다.
- 네트워크 커뮤니케이션을 최적화할 수 있으며 호출 횟수와 반환되는 데이터의 크기를 많이 절약할 수 있다.
- 리퀘스트의 리스폰스는 저장이 가능한지 여부와 가능하다면 얼마나 저장할 수 있는지를 명시해야 한다.
- 데이터 변경 여부에만 관심이 있다면, GET 대신 HEAD 리퀘스트를 사용할 수 있다.
레이어드 시스템 제약사항
클라이언트가 서버와 상호작용을 할 때, 오직 서버만을 알고 있어야 한다. 서버를 이루는 인프라스트럭쳐는 계속 뒷단에 숨겨져 있어야 한다. 클라이언트는 시스템에서 오직 하나의 레이어만을 볼 수 있어야 한다.
코드 온 디멘드 제약사항
서버는 필요하다면 클라이언트에 실행 가능한 코드를 전송할 수 있어야 한다. 이 제약사항은 선택적 이다.
- 특정한 목표나 규칙적인 목표를 통해 적절한 데이터를 제공함으로써 일종의 코드 온 디멘드를 달성할 수 있다.
유니폼
모든 상호작용은 식별된 리소스의 개념에 따라 이루어져야 한다. 이는 식별된 리소소의 조작은 리소스의 상태 표현들과 표준 메서드들을 통해서만 이뤄짐을 의미한다. 또한, 상호작용은 리소스의 표현이 무엇을 의미하는지와 이 리소스들로 무엇을 할 수 있는 모든 메타데이터를 제공해야 한다.
- 네이밍 컨벤션은 속성의 이름, 쿼리 파라미터의 이름, 코드, OpenAPI파일의 JSON Schema 등에 대해서도 정의할 수 있다. 일단 네이밍 컨벤션을 정했다면, 엄격하게 따를 의무가 생긴다.
💁일관된 API를 디자인하면 API의 사용을 용이하게 할 뿐만 아니라 디자인도 더 단순하게 만든다.
- 동작을 추측할 수 있는 API를 작성하려면 일관된 규칙을 정의하고 일반화된 사례나 표준을 준수한다.
- 항상 API가 다른 포맷을 지원하거나 현지화 또는 국제화를 지원해야 하는지 확인한다.
- 목록 형태의 목표를 제공해야 한다면 페이지, 필터, 정렬 기능이 추가될수록 사용성이 증진된다.
- 컨슈머에게 많은 API를 안내하기 위해 가능한 많은 메타데이터를 제공한다.
- API가 예측 가능하게 하고, 사용자가 혼란을 겪지 않도록 지나치게 복잡하거나 전혀 익숙치 않은 기능은 제공하지 않는다.
