나의 고찰 1 - 백엔드 입장에서 보는 유의미한 데이터란?? (봉투패턴)

웹에선 HTTP 통신 프로토콜을 이용해 서버와 클라이언트 사이에서 통신을 한다.

그 프로토콜등을 이용해 우리는 원하는 데이터를 전달받을 수 있는데, 이러한 과정 속에서 궁금한 점이 생겼다.

 

우리는 그저 프론트에서 요청하는 데이터를 정확하게 전달해주면 백엔드는 그 역할이 끝났다고 생각한다.

 

원하는 데이터에 대한 로직을 검증하고 수행하는 역할은 백엔드에서 진행하고, 그 결과에 맞춰 프론트가 요청하는 데이터를 전달해주면 된다.

 

그럼 프론트 입장에서는 프론트로 전달되는 데이터들은 유의미한 데이터이며, 유의미해야만 한다고 생각이 들었다.

기존에 미니 프로젝트나 명세가 있으면 요구하는 데이터를 전달하면 되는데, 만약 그것이 없다면 어떤 데이터를 전달해야할까? 백엔드는 결국 요청에 대한 응답을 진행하는 거니까? 이 유의미한 데이터에 대해 뭔가 많은 생각을 하게 되었다.

 

그래서일까 이 데이터를 전달할 때, 궁금증이 생겼다. 기존에 데이터를 전달할 때, 그냥 DTO를 이용해서 데이터를 많이 전달하고 데이터를 반환하지 않거나 등 여러 방식으로 해당 기능이 동작하는지를 확인할 수 있다.

 

오늘 내가 하고싶은 이야기는 봉투패턴에서 전달할 수 있는 데이터에 관한 이야기를 해보려고 한다.

 

요즘엔 많은 서비스들이 Rest Api 형식을 채택해서 사용하고 있는데 이 rest api의 특징은 데이터를 Json 형식으로 전달하는 것이다.

 

어떤 특정 객체를 JSON 형식으로 표현하면 다음과 같다

{
	"id" : 1,
	"title" : "제목",
	"content" : "내용"
}

 

이렇게 데이터를 전달할 수 있는데, 만약에 데이터 리스트를 조회한다면? 아래와 같을 것이다.

[
    {
        "id":1,
        "title":"제목",
        "content":"내용"
    },{
        "id":2,
        "title":"제목",
        "content":"내용"
    },
    ...
    {
        "id":99,
        "title":"제목",
        "content":"내용"
    }
]

만약 여기서 총 작성된 게시물의 갯수를 구하고자 한다면?? 물론 우리가 시각적으로 id 값을 확인하면서 데이터의 갯수를 확인할 수 있지만, 혹여나 중간에 지워진 데이터가 있다면? 헤아리기 힘들 것이다. 

그래서 우리는 count를 추가해서 데이터를 전달할 수 있는데, 이 때 각 멤버마다 넣어주는 방식밖에 없어서 각 멤버에 데이터에 찍혀서 나올 것이다

 

그렇기에 데이터의 중복의 문제도 있으며, 이 데이터가 우리가 의도한 데이터인지 아닌지 유무를 정확히 파악하기 힘든데, 이 때 API의 확장성을 유지하기 위한 방법이 Envelope Pattern이다. 

 

위 데이터를 한번 더 감싸서 아래와 같은 방식으로 전달할 수 있다.

{
"code":"success",
 "data":{
	"board" :  [   {
            "id":1,
            "title":"제목",
            "content":"내용"
        },{
            "id":2,
            "title":"제목",
            "content":"내용"
        },
        ...
        {
            "id":99,
            "title":"제목",
            "content":"내용"
       	 }
	]
 }
}

 

여기서 궁금증이 생겼는데, 이 패턴에서 전달하는 데이터와 관련된 궁금증이었다.

응답의 형태에 관련해 궁금증이 생겼는데 어떤 응답의 형태를 보여줘야할까? 에 대한 궁금증과, 이 데이터가 과연 유의미한 데이터인가?에 대한 궁금증이었다.

 

보통 code, data, message 정도를 캡슐화해서 데이터를 전달하는데, 더욱 추가적인 정보도 전달할 수 있다.

• code : HTTP Status로 표현할 수 없는 상태 값
• data : 요청에 따른 응답 데이터
• message  : 해당 API가 성공할 땐 null, error가 발생했을 땐 해당 에러에 대한 정보

 

이 봉투패턴을 사용함에따라 API의 확장성이 늘어난다. 

(원하는 결과를 추가로 얻을 수 있으니까?)

 

그래서 이 데이터의 규격과 과연 이러한 데이터들이 의미가 있는 데이터일까?

일반적으로 현업에서는 어떻게 활용하나?

또한 이러한 상태 코드들을 내가 하고싶은대로 만들어서 전달해도 되는 것인가?

 

등 여러가지 궁금증에 관한 이슈들이 있었는데 얻은 혜안은 다음과 같았다.

 

• 개인의 취향
• 회사마다 규격이 있을 것이다 -> 그 규격을 따를 것.
• 가독성이 증가한다?

 

정해져 있지 않으니까 결국 쓰기 나름이다로 귀결 << 내가 내린 결론이다.

 

그래서 데이터를 전달할 때, 패턴 속에 조금 더 유의미한, 가치있는 데이터를 전달할 수 있도록 노력해야겠다고 생각했다.

또한 내 마음대로 상태 코드를 만들어서 사용하기 보단 HTTP 상태 코드의 규격을 살펴보고 이미 이 HTTP 상태 코드는 약속이기에 기준을 HTTP 코드로 설정하고 확장해서 본질을 잃지 않도록 사용해야겠다고 의미를 부여했다.

 

 

참고 자료

 

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

HTTP 상태 코드 - HTTP | MDN

https://okky.kr/questions?keyword=status&page=1 

OKKY - Q&A

https://www.marklogic.com/blog/envelope-design-pattern/

Design Patterns: The Envelope Design Pattern - MarkLogic