Feed API Specification

1. Feed
2. Comment
3. Likes

0️⃣ 타입 정의

interface Image {
  id: number;
  imageUrl: string;
}

interface Feed {
  id: number;
  userId: number;

  user: {
    id: number;
    profileImage: string;
    name: string;
  };

  title: string;
  content: string;
  images: Image[];

  updatedAt: string;
}

interface Comment {
  id: number;

  user: {
    id: number;
    profileImage: string;
    name: string;
  };

  content: string;
  updatedAt: string;
}

🚨 질문 리스트

1. 작성 완료, 좋아요 성공, 신고 성공에 대한 응답 데이터는 무엇으로 설정해야 하나요? ✅ 피드백 4
2. 게시물, 유저와 같은 고유 Id 타입 확정 필요 (string vs bigint) ✅ 피드백 1
3. 팔로우 여부와 자기 게시물 여부에 대한 여부 체킹에 대한 방법 ⚠️ 추후 변경가능
   • 변수 하나로 체크하는 방법 relationshipStatus: 'self' | 'following' | 'none'
   • 변수 두개로 체크하는 방법 isFollow: boolean isSelfFeed: boolean
4. 공개 범위 변수 명 어떤 걸로 정의하는게 좋을까 ✅ 피드백 5
5. 신고하기 사유에 대한 변수명과 타입을 어떻게 설정하는 것이 좋을까? ✅ 피드백 3

✍️ 피드백

1. 모든 id는 number로 관리해도 무방할 듯. BIGINT의 값이 -9223372036854775808 ~ 9223372036854775807인데, unsigned로 관리하면 이 값을 넘을 일이 거의 없을 것이라 판단. (단 java 에서는 BigInteger 타입으로 치환해야 할 수도 있으나 과연 Long 범위를 넘을 일이 있을까?)
2. API 응답 데이터는 스네이크 케이스가 아닌, 카멜 케이스로 사용된다.
3. 현재 문의하기 API에서는 category로 분류하고 있으니 통일성을 위해 여기에서도 category로 하면 좋을 것 같다.
4. images: string[]; -> 사진 경로만 받아오면 FE단에서 key값 부재로 인해 관리가 힘들지 않을지? id, url 함께 넘기는 배열 타입을 보내줄 수 있음. 응답 데이터가 필요하다면 그에 맞추어 데이터를 넘겨드리겠지만, 아마 필요없지 않을까요? 그럴 때는 다음과 같은 응답 포맷을 반환합니다.

   {
     "code": "2000",
     "data": {}
   }

5. BE에서도 public, friend, private를 사용할 것 같습니다.
6. RESTful 명세에 의해 요청 url은 /feeds/{feed_id}, 즉 query param을 사용하지 않음.
7. 피드 상세에서 굳이 feed와 comment를 join할 필요가 있을지? /feeds/{feed_id}와 /feeds/{feed_id}/comments를 비동기 요청으로 받는 게 서로 편할 거라 생각함
8. Feed List에서 feedId랑 userId를 받아올 수 있으니까 이걸로 게시물 정보 보여주고, 다시 요청해서 작성자와의 관계 및 isLike, isBookMark 받아오게 하면 될듯
   • 이 방법이 아니라면 Join 횟수가 너무 많아져서 오히려 시간이 더 걸릴 수도 있음
9. report, bookmark 등 단수 명사는 복수 명사로 변경
10. likeCount는 like에 대한 API 요청으로 받아오는 응답 데이터이므로 totalCount로 변경하는게 좋을 듯!