REST API (Self-descriptive messages)

Question

안녕하세요 강의 잘 듣고 있습니다.   실습에서 '/good' 은 Self-descriptive messages가 잘되어있고, '/bad'는 Self-descriptive messages가 잘 되어있지 않았다고 설명해주셨는데 강의 내용만 보고는 잘 이해가 안가서 이부분 좀 더 자세히 설명 듣고 싶습니다.   감사합니다.

큰돌 · Answer

안녕하세요 동헌님 ㅎㅎ 핵심은 “헤더가 말하는 데이터 형식”과 “실제 바디 데이터”가 일치하느냐입니다. Self-descriptive messages는 이 두 개가 정확히 맞아야 성립합니다. 먼저 /good 을 보면: app.get('/good',(req, res) =>{ res.status(200).json({"a" : 1}) }) 여기서 res.json() 은 내부적으로 두 가지를 자동으로 처리합니다. 헤더: Content-Type: application/json 바디: { "a": 1 } (정상적인 JSON) 즉, 클라이언트 입장에서는 “이 응답은 JSON이다”라는 정보(헤더)와 “실제로도 JSON 데이터”(바디)가 일치합니다. 그래서 별도 설명 없이도 바로 JSON으로 파싱할 수 있습니다. 이게 Self-descriptive가 잘 된 상태입니다. 반면 /bad 를 보면: app.get('/bad',(req, res) =>{ res.setHeader('content-type', 'application/json'); res.send("큰돌이") }) 여기서 문제가 발생합니다. 헤더: application/json → “JSON이다”라고 선언 바디: "큰돌이" → 단순 문자열 (JSON 객체/구조 아님) 즉, 헤더와 실제 데이터가 불일치 합니다. 클라이언트 입장에서 보면: “JSON이네?” → JSON 파싱 시도 그런데 실제 데이터는 JSON 형식이 아님 파싱 오류 또는 예상과 다른 동작 발생 이 상황은 메시지만 보고는 제대로 해석할 수 없습니다. 즉, Self-descriptive하지 않습니다. Self-descriptive messages는 “헤더만 보면 이 데이터를 어떻게 처리해야 할지 확정할 수 있어야 한다”는 개념입니다. /good → 헤더를 믿어도 문제 없음 /bad → 헤더를 믿으면 오류 발생 그래서 /bad 는 Self-descriptive 원칙을 깨는 사례입니다. 조금 더 실무적으로 보면 이렇게 이해하면 정확합니다. Content-Type = 계약서 Body = 실제 납품물 /good → 계약서와 납품물이 일치 /bad → 계약서는 JSON인데 실제는 엉뚱한 데이터 이 계약 불일치가 바로 Self-descriptive 위반이라고 보시면 됩니다.       또 질문 있으시면 언제든지 질문 부탁드립니다. 좋은 수강평과 별점 5점은 제게 큰 힘이 됩니다. :) 감사합니다. 강사 큰돌 올림.