•
API 문서 읽기
◦
[패턴] “프론트 입장에서 API는 기획 문서에 가깝다” → 문서를 볼 때 설명 그 자체보다는 → (전체적인 플로우를 떠올리면서 → 이건 언제 이렇게 쓰이고…(추측)) → (맞추든 틀리든 추측한다는 행위 자체가 중요)
◦
[패턴] API 문서를 보고 인터페이스를 만들 때 좀 더 신경을 써서 보는 것들이 있다
▪
type 등을 눈여겨 보면 더 나은 조건 분기를 할 수 있다 (ex. grid, list, select) → enum? discriminated union?
▪
ex. “아, 아까 요구사항 봤을 때 입력 받아서 결국 서버에 보내주는 API가 필요했는데 그게 이거구나.” → 보낼 데이터의 모양이 필요하니까 인터페이스로 만들어야지 → 결국 그 모양을 만들어주려면 그 중간 과정의 뭔가 필요하겠구나.
•
서버 → 클라이언트: FooResponse
•
클라이언트 → 서버: FooRequest
•
예시: PostOrderDetailRequest → Post / Order / Detail / Request (주문 상세에 대한 정보를 서버로 요청할 때 사용하는 인터페이스)
•
모양이 같다고 다 같은 타입으로 쓰지 않음 → 구조적 동일성과 시맨틱을 분리하여, 변경에 열려 있도록 함
◦
구조적 동일성과 시맨틱을 분리함: 서버로 보낼 때 쓰는 PostOrderRequest와 서버에서 받아온 개별 Order 타입이 동일한 구조를 갖고 있다고 해서, Order를 모든 곳에 쓰지 않음 → type alias를 사용해서 타입에 의도를 보존해 둠
export type GetOrderDetailResponse = Order;
TypeScript
복사
◦
서버 인터페이스(Response)와 클라이언트 인터페이스(Entity) 개념을 분리하여 변경 유연성 확보
export interface ItemEntity {}
export interface ItemsResponse {
items: ItemEntity[];
}
TypeScript
복사
