리포트 기능 API에 대하여 논의한다.

[bperhaps]

@devhyun637

리포트의 POST 관련해서, 사용자에게 보여줘야 하는 정보보다 많은 정보를 주고 있는데 이부분에 대해서 ‘프롤로그에서 모든 학습로그 데이터를 저렇게 주기로 약속한 것인지’, 아니면 손너잘의 의견인지 궁금합니다.

사실 이 부분에대해서 고민을 많이 했는데요, 어제 프론트의 상태관리 기법에 대해 여쭤본게그 이유였습니다.
먼저, 현재 제가 알고있는 프로트엔드의 스팩은 SPA를 적용하고 있으며 모든 컴포넌트에 대한 상태관리를 리덕스에서 진행하고 있다는 것 입니다. 따라서 서버로의 요청을 최소화 하고 프론트엔드에서 데이터의 상태가 최대한 관리되는 방향으로 개발이 진행된다고 생각했습니다.
가장 먼저 Report의 등록부분에 대해 설명을 드리자면, 어떤 리소스를 등록(POST)한 뒤에는 일반적으로 생성된 리소스를 사용자에게 보여주는 플로우가 발생한다고 생각합니다. 이때 생성된 리소스를 제공하는 방법에는 크게 2가지가 있다고 생각합니다.

• 생성된 리소스의 id만 제공한다, 추후 클라이언트는 id기반으로 query한다.
• 생성된 리소스의 데이터를 반환한다. 추후 클라이언트는 응답받은 데이터를 기반으로 페이지를 구성한다.

제가 이해한 프론트의 스팩으로 보았을 떄 후자가 맞다고 생각하여 전체 Reposrt를 반환하도록 설계해 봤습니다. 만일 전자가 맞다면, Locations헤더에 /reports/{reportsId}를 담아 반환하도록 하겠습니다. 아니라면, 원하는 데이터 형식을 말씀해 주시면 반영하도록 하겠습니다(PUT도 동일하게 반영하겠습니다) :)

수정 요청에 대한 응답에 바디(역량정보)가 필요할까요?
프론트에서 요청한 것이라면 주는게 좋겠지만
제가 생각할 땐 수정 후 다시 조회 요청을 보내는게 API의 의도가 명확할 것 같아요!

위에서 설명한것과 동일한 이유로 이렇게 설계했었습니다! 의견 주시면 반영하겠습니다! :)

삭제 요청에 대한 응답에 바디(역량정보)가 필요할까요?
프론트에서 요청한 것이라면 주는게 좋겠지만
제가 생각할 땐 삭제 후 다시 조회 요청을 보내는게 API의 의도가 명확할 것 같아요!

앗! 이부분은 설계 미스입니다.ㅜㅜ 없는 리소스에 대한 정보를 줄 수 없지요...

abilityGraph는 그래프에 종속적인 네이밍이 될 것 같아요!
reportAbilities 라고 하면 어떨까요?
reportAbilities: [
{
ability: Number,
weight: Number
}, ...
]

처음 생각했을때, 역량을 보여주는 부분과 그래프를 크게 묶으면 하나의 컴포넌트라고 생각해서 네이밍 한건데, 티케의 의견이 맞는 것 같습니다.
다만 현재 전송하는 데이터가 report라는 리소스의 메타데이터라는 사실이 URI에 /reports로 명시되어 있다고 생각합니다. 이 점에서 바라보았을 때 네이밍에 report가 붙는것은 의미의 중복이라고 생각하는데요. (백엔드의 기준에서 봤을때 report.getReporrtAbilities() 와 같은 형식으로 데이터를 불러오게 됩니다.) 이러한 네이밍은 사실 객체지향적 관점에서 봤을때 그리 좋은 네이밍은 아니라고 생각합니다(조영호, 에고르). 또한 각 역량을 나타내는 object의 경우, 식별자의 네이밍을 변경할 경우 해당 Entity에 대한 참조 및 비교가 기술적으론 가능하나 의미론적으로 이상해 진다고 생각하여 id라는 네이밍을 그대로 가지고 가고 싶은데 어떻게 생각하시는지 궁금합니다 :)

abilities: [
    {
        id: Number,
        weight: Number
    }, ...
]

posts: [
{
id:Number,
abilities: []
}, ...
]
여기도 reportPosts로 하면 어떨까요?
굳이 report를 붙이는 이유는 기존 post와 차이를 두기 위해서 입니다 :)

이에 대한 저의 의견도 동일합니다 :) 해당 데이터가 어느 리소스의 데이터인지는 URI에 명시되어 있기 때문에(https://restfulapi.net/#Resource) report를 다시한번 명시하지 않아도 된다고 생각합니다. 프론트를 잘 모르기때문에 확실한 답변이 될 수 있을 지 모르겠지만 예시코드를 간단히 작성해 보자면

let reports = await getAll("/reports");
let reportPosts = reports.map(report => report.post);

위와같은 식으로, 코드상에서 변수명을 통해, 그리고 URI를 통해 그 의미가 충분히 전달된다고 생각하는데 이에 대한 티케의 의견도 들어보고싶네요!

Discussion

• Post 및 Put 요청에 대한 응답을, id값만 줄 것인가 전체 데이터를 줄 것인가?
• id값만 준다면, body에 넣어 줄 것인가 Locations 헤더에 uri형태로 줄 것인가?

[devhyun637]

제가 질문드린 부분에 대해서만 질문의 의도와 예상했던 API 명세를 말씀드리겠습니당
아 그리고 제가 왜 대문자로 썼는지 모르겠는데 POST 가 http 메소드가 아니라 posts에 관해서 질문한 거였습니다...!
일단 저희는 현재 상태관리를 리덕스로 관리하고 있지 않고, 만약 상태관리를 하더라도 기존의 학습로그와 리포트의 학습로그는 별개입니다. 리포트 안에서 학습로그가 수정될 일도, 학습로그의 역량이 부과된다고해서 영향을 미치는 부분이 없습니다. 따라서 제가 상태관리를 하게 된다면, 리포트 상태를 따로 관리할 것이라고 생각이 들어서 posts 부분에 대해서 다음과 같은 명세를 예상했습니다. 제가 잘못이해한 부분이 있다면 알려주세요!!

posts: [
	{
	    id:Number,
	    createdAt:Date,
	    updateAt:Date,
	    title:String, 
            mission: {   // 현재 미션이 아니라 레벨로 이야기가 된 부분이긴한데, 이 부분도 정말 필요한 부분인지는 의문이군요 👀
				id:Number,
				name:String
	   },
	    abilities: [ 
			{
				id:Number,
				name:String,
				color:String
				}, ...
			]
		}, ...
  ],

[devhyun637]

posts 좋습니당!!

추가적인 질문&요청으로, 사용자가 자신이 대표로 지정한 레포트가 가장 먼저 보이게 하는 방법을 지금 생각하고있는데,
리포트 리스트 GET요청을 했을 당시에, 대표 리포트에 대한 정보가 있었으면 합니다. 어떻게 생각하시나용?.?

[gracefulBrown]

음.. 가장 최신 리포트를 먼저 보이게 하는거보다 대표 리포트를 지정하는게 나을꺼라는 말씀이시죠?

[devhyun637]

넵 저는 그렇게 생각을 했는데 브라운 의견은 어떠하신가용

[gracefulBrown]

저는 그냥 최신 리포트 보여줄 생각이었는데 대표 리포트도 괜찮겠네요ㅎㅎ
대표 리포트 지정을 안하면 최신 리포트 보여주고 지정하면 그 리포트를 먼저 노출하기!
좋습니다ㅎㅎ

[gracefulBrown]

그럼 리포트 목록 조회할 때 reports와 같은 계층에 representReport값이 있어야 겠네요

[gracefulBrown]

제가 남긴 의견은 다 답변이 된 것 같습니다!ㅎㅎ
수정되는 부분이 있으면 링크 남겨주시고 이 디스커션은 닫아도 될 것 같네요 :)