[Data] 메세지 표준 규격

글을 시작하며

오늘은 JSON, yaml, xml에 대해서 이야기를 하려고 합니다. 관심이 있으시다면, 끝까지 읽어주세요~!!

A/와 B는 팀 프로젝트를 마치고 함께 보고서를 쓰게 되었습니다. 하나의 보고서를 내야하는데, 분량이 많아서 나눠서 쓰기로 합니다.

각자가 쓰고 하나로 합치려고 보니, A는 워드로 작성을 했고, B는 한글로 작성을 했던 것입니다. 한 파일로 합쳐보았지만, 용지 규격도, 폰트도 달라서 그림과 표의 위치가 엉망이 되었습니다.

어떤 방식으로 보고서를 쓸지 미리 정한다면, 위와 같은 상황을 막을 수 있을 것입니다.

즉, 데이터를 전달할 일이 있다면 기준이 되는 ‘규격’ 이 있다면 좋을 것입니다.

메세지 표준 규격

클라이언트와 서버가 메세지를 주고 받을 때도, 데이터를 어떻게 주고 받는지가 중요합니다.

그래서 이들 간에도 규격이 있습니다.

그것은 오늘의 주인공이 JSON, yaml, xml 입니다.

JSON, yaml, xml

이 규격들은 모양, 허용되는 인코딩, 주석 가능 여부 등에 차이가 있습니다.

표를 보고 조금 더 자세히 알아봅시다.

	JSON	yaml	xml
	'키'와 '값'으로 된 객체 (중괄호{ } 사용)	JSON과 유사 (스페이스로 값 구분, 탭X)	html와 유사 (태그< > 사용)
모양	{      key : value,      key : value }	key : value key :     key : value	<?xml version=”1.0” encoding=”UTF-8”?> <key> value </key>
인코딩 허용	UTF-8	UTF-8, UTF-16 (자바 설정 파일이 application.yml 인 이유~!)	문자 인코딩 직접 지정 (위의 예시처럼 인코딩을 코드에서 직접 지정)
주석 기능	❌	⭕️ (#)	⭕️ (<!-- -->)
사용 예시	- 서버/클라이언트 간 대표적인 메세지 규격	- 자바 application.yml과 같은 설정 파일	- AWS의 RESTful API 응답 형식 - Mybatis 사용 시 Mapper
널 값	null	~
한계	- 읽기는 쉽지만, 표현 비용 큼   (텍스트라서) - 호환성 유지 어려움   (서버에서 key변경 시) - 주석 불가	- JSON만큼 범용적이지 않음 - 간격 중요 (탭 허용 X)	- 단순 데이터 전달 용으로 쓰기엔 복잡

이번에도 느낀 것이지만, 새로운 개념을 공부할 때, 기존에 알던 것을 기반으로 이해하게 됩니다. 가령,

1. 내가 경험했던 yaml파일이 무엇이 있었지? 전 application.yml이 떠올랐습니다.

   => 아 그리고 자바 설정 파일이라서!! JSON이 아닌 yaml이구나.

      (자바의 경우, UTF-16 인코딩이 필요합니다~!)

2. xml은 Maven 프로젝트일 때, pom.xml도 있고, Mapper로도 썼었는데!

   => xml 사용 예시로 적으면 되겠다!

이렇게 기존 개념들이 연결되었을 때의 기분은 최곱니다. 🚀🚀🚀