개요
최근 API 개발 업무를 담당하고 있다. 기능 개발 자체는 애플리케이션 내부에서 발생하기 때문에 크게 어려움이 없었는데, 애플리케이션 외부와의 요청 및 응답을 처리하는 과정에서 애로사항이 발생했다.
관련해서 기억해 둘 만한 부분을 적어둔다. 참고로 대단히 경험적인 이야기다…….
JSON 데이터 생성은 생성기를 사용한다.
일반적으로 데이터를 주고받는 형식 중 하나인 JSON은 문자열 데이터이다. 프로그래머가 코드에서 문자열 객체로 JSON 데이터를 만들거나 프로그래밍 언어에서 지원하는 JSON 관련 라이브러리로 데이터를 만들 수 있다.
당연한 말이지만 JSON 형식 데이터를 문자열로 직접 생성하는 것은 지양하는 것이 좋다. 사람이 JSON 문자열을 다루는 경우에는 큰따옴표가 아니라 따옴표를 사용하여 문자열 키나 값을 묶을 수도 있을 뿐만 아니라, 콜론이나 쉼표가 잘못 배치될 가능성이 너무나도 높다. MDN Web Docs에서도 생성기 프로그램 등으로 만든 JSON 데이터가 오류가 적다고 기재해 두었다.
유효한 JSON 데이터를 주고받을 수 있도록 JSON 데이터는 반드시 라이브러리 등에서 제공하는 JSON 데이터 생성기를 이용하도록 한다.
header 대소문자를 제어하는 라이브러리는 지양한다.
HTTP는 기본적으로 헤더의 대소문자를 구분하지 않는다. 하지만 애플리케이션은 내부 제약사항 등으로 인해 헤더의 대소문자를 구분할 수도 있다. 대표적으로 AWS API Gateway가 예시가 될 수 있다.
때문에 AWS API Gateway와 같은 HTTP 헤더의 대소문자를 구분하는 애플리케이션으로 요청을 보낼 때 헤더의 머릿글자를 대문자로 변경하는 Python Tornado를 사용하면 헤더가 유효하지 않은 것으로 취급되어 요청이 거절될 수 있다. 이런 경우, 사용 라이브러리의 변경이라는 큰 수정사항이 발생한다.
따라서 요청을 보낼 때 헤더의 대소문자를 제어하지 않는 라이브러리를 사용할 필요가 있고, 서버를 개발할 때에도 HTTP 표준에 알맞게 대소문자를 구분하지 않는 방향으로 개발하는 것이 좋겠다.
응답 정보 로깅
요청 완료 후 서버로부터 받은 응답은 상태 코드처럼 별도로 파싱 하지 않고 사용할 수 있는 정보를 사용하여 로그에 정보를 기록하는 것이 좋겠다.
응답 정보를 별도로 파싱한 뒤에 로그를 남기면 응답을 파싱 하는 과정에서 문제가 발생했을 때 남아있는 정보가 없어 어떤 응답을 받았는지 알 수 없게 된다. 이렇게 되면 디버깅하기도 어려울뿐더러 오류가 발생하고 대응하는 과정에서 불필요한 중복 요청이 발생할 수 있다.