5장 도메인 특화 설계
요청을 보내고 클라이언트가 되돌려 받는 하이퍼미디어는 미로의 길을 알려줄만큼 다음 선택지에 대한 정보를 제공해야 한다.
클라이언트는 그들의 원하는 일을 한다
미로 지도라는 리소스의 표현에서 출구를 찾던, 지도를 작성하던, 요청 몇개 보내고 지도를 완성했다고 거짓말을 하던 상관이 없다. 클라이언트와 서버는 서로 주고받는 표현의 이해를 공유하고 있어야 하지만 풀어야 하는 문제가 무엇인지 함께 인식할 필요는 없다.
표준 확장하기
미로를 3차원으로 확장한다면 어떤 클라이언트는 작동에 이상없으나 어떤 클라이언트는 문제가 생긴다.
지도 제작기의 결점
특정 서버 구현에 맞춰 동작하게 만들어진 클라이언트는 그 서버의 특징에 최적화될 수 있겠지만, 동일한 표준을 구현하는 다른 경우에는 동작하지 않을 수 있다. 클라이언트 구현은 하나의 서버 구현이 아니라 모든 서버 구현에 대해 동작하도록 설계해야 한다.
해결책(그리고 해결책의 결점)
기존 지도 제작기가 해석하지 못하는 데이터에 대해 알려줘서 해결할 수 있다. 그렇다고 그게 다시 완벽한 작동을 의미하는 것은 아니다.
비유로서의 미로
지금껏 미로에 대해 이야기한걸, 하이퍼미디어에도 적용 가능하다. 어떤 하이퍼미디어는 혼란스럽고 무한하게 큰 반면, 어떤 것은 정갈하고 모범적이라 탐험하기 쉽다.
의미 체계의 문제 맞닥뜨리기
특정 도메인을 위한 API 설계자에게 의미적 차이를 이어주는 두 단계의 과정
- 사람이 읽을 수 있는 규격으로 애플리케이션 의미 체계를 작성
- 설계에 따라 하나 이상의 IANA 미디어 유형을 등록하고, 1의 문서와 연계한다.
클라이언트 설계자는 반대로 진행한다.
- 모르는 미디어 유형을 IANA에서 찾아본다.
- 어떻게 다뤄야 할지 사람이 읽을 수 있는 규격으로 배운다.
도메인 특화 설계는 어디에 있는가?
API를 공개해야 할 때 처음 할 것은 기존의 도메인 특화 설계가 있는지 찾아보자.
미로 탐험의 끝에 받는 상
하이퍼미디어 컨트롤 : 1~2장에서 나왔듯, 리소스의 상태를 변경할 수 있는 하이퍼미디어
바이너리 이미지 형식 : 이미지를 이진법 데이터로 저장
JPEG이 하이퍼미디어 컨트롤이 없다고 새로운 바이너리 이미지 형식을 만드는 것은 어리석은 일이다?
- 사진은 입력 폼이나, 버튼처럼 리소스의 상태를 변경하기 위해 사용되는 하이퍼미디어가 아니다
- 그럼 이건 하이퍼미디어가 아니니 바이너리 이미지 형식으로 처리하기 쉽게 바꿔줘야 하나?
- 그 사진은 하이퍼미디어로 구성된 미로의 결과물이지, 미로의 구성물이 아니다.
애플리케이션 의미 체계 훔치기
도메인 특화 데이터 형식은 문제 도메인의 애플리케이션 의미 체계를 식별하는 데 많은 시간과 비용이 든다.
도메인 특화 설계를 찾을 수 없다면 만들지 말라
그렇다.
API 클라이언트의 종류
- 사람이 조종하는 클라이언트
- 자동 클라이언트
- 크롤러
- 모니터
- 스크립트 : 변하지 않는 특정 작업 루틴을 가진 사람을 흉내낸다.
- 에이전트 : 사람만큼 똑똑하지 않고, 주관적인 결정을 내릴 수는 없지만, 동일한 상황에서 사람이 하는 것을 한다. 표현을 보고, 상황을 분석하고, 어떤 하이퍼미디어 컨트롤을 활성화하는 것이 최종 목표에 더 가까워지게 할지를 결정한다.
