[FEAT] 카테고리 순서 변경 가능하도록 변경

[Hain-tain]

📌 어떤 기능인가요?

추가하려는 기능에 대해 간결하게 설명해주세요

📜 작업 상세 내용

BE

• 카테고리 생성시 마지막 순서로 생성한다.
• 카테고리 순서를 변경할 수 있다.
• 카테고리 삭제 시 순서를 조정한다.

FE

• TODO
• TODO

⏳ 예상 소요 시간 (예상 해결 날짜)

이슈를 완료하기까지 예상되는 소요 시간을 시간 or 일 단위로 작성해주세요.

0일 0시간 소요 (00/00 00:00)

🔍 참고할만한 자료(선택)

[HoeSeong123]

API 수정사항 (1차)

제 개인적인 생각일 뿐 추가적인 의견 있으면 얼마든지 얘기해주세요!

카테고리 목록 조회

Response

// before
{
  "categories": [
    {
      "id": 1,
      "name": "Spring"
    }
  ]
}

// after
{
  "categories": [
    {
      "id": 1,
      "name": "Spring",
      "ordinal": 1
    }
  ]
}

카테고리 수정

카테고리 수정의 경우 현재는 수정하고자 하는 카테고리의 Id를 경로 매개변수로 담아 요청을 보내고 있습니다.
즉, 하나의 카테고리에 하나의 요청이 오고 있습니다.

하지만 이제 순서를 변경해야 하기 때문에 리스트로 묶어서 보내야 합니다.
아래와 같은 문제가 발생할 수 있기 때문입니다.

• 예시: 1번과 2번의 순서를 변경한다.
  • 1번 카테고리에 대해 수정 요청이 간다.
    • 순서가 수정된다.
  • 2번 카테고리에 대해 수정 요청이 간다.
    • 예상치 못한 에러가 발생한다.
  • 이 경우 1번 카테고리는 순서가 변경되었지만 2번 카테고리는 순서가 변경되지 않게 된다.

따라서 수정 요청을 한 번에 처리하여 만약 예외가 발생하면 1번과 2번 모두에 대해 롤백을 진행해야 합니다.

Request

// before
PUT /categories/{id}
{
  "name": "Spring"
}

// after
PUT /categories
{
  "categories": [
    {
      "id": 1,
      "name": "Spring",
      "ordinal": 1
    }, 
    {
      "id": 2,
      "name": "Java",
      "ordinal": 2
    }
  ]
}

카테고리 삭제

카테고리 삭제도 수정과 마찬가지로 리스트로 묶어서 보내는 것이 좋을 것 같습니다. 또한 Id 뿐만 아니라 순서도 같이 보내주면 좋을 것 같아요.
id만으로 조회해서 삭제 후 순서를 조정하는 것이 쉽지 않더라구요..

//before
DELETE /categories/{id}

//after
DELETE /categories
{
  "categories": [
    {
      "id": 1,
      "ordinal": 1
    }, 
    {
      "id": 2,
      "ordinal": 2
    }
  ]
}

[zangsu]

짱수 의견 1 - 모든 요청을 분리해 두자.

• 카테고리 개별 요소의 생성 / 업데이트 (이름 변경) / 삭제 모두 XXX categories/{id} url 로 보낸다.
• 순서 변경시 PUT categories/ordinal url 로 보낸다.

이유: 모든 생성 / 수정 / 삭제 요청이 하나의 엔드포인트에서 처리된다면 그 로직이 매우 복잡해진다. (like 우리의 소스코드 수정)
최대한 categories 엔드포인트로 처리되는 로직을 줄이기 위한 의견

+) 추가적으로, "취소" / "저장" 버튼을 사용하지 않고 매 수정마다 요청을 보내 처리한다. 요청이 처리되는 동안 카테고리 모달을 블로킹한다.

[jminkkk]

카테고리 수정

API를 최대한 분리하자

View에 의해 API가 무거워지는 것은 좋지 않은 현상인 것 같슴다...! (로직도 복잡해짐)

순서 변경

PATCH /categories/{id}/ordinal

• 카테고리를 몇번으로 옮기는지 전후 순서가 필요

동시에 여러 요청이 오는 경우 뒤섞일 수 있을 것 같아요. 이 상황에서는 2가지 방식이 있을 것 같네요.

1. 모든 순서를 다 받아서 변경감지
2. 요청은 응답이 무조건 도착해야지 다음 요청 처리

이름 변경

PUT /categories/{id}

[zeus6768]

TemplateUpdate처럼 PUT으로 모든 변경을 처리하기.

PUT /categories?memberId=1
Content-Type: application/json

{
  "createCategories": [
    {
      "name": "카테고리 1",
    },
    {
      "name": "카테고리 2",
    }
  ],
  "updateCategories": [
    {
      "id": 3,
      "name": "카테고리 3",
    },
    {
      "id": 4,
      "name": "카테고리 4",
    }
  ],
  "deleteCategoryIds": [5, 6]
}

public record UpdateCategoryRequest(
    List<CategoryRequest> createCategories, 
    List<CategoryRequest> updateCategories,
    List<Long> deleteCategoryIds
)

[kyum-q]

순서 변경 API를 따로 분리했을 때 걱정

순서 변경 API를 분리하는 방식이 문제를 일으키지 않는다면, 그 방법도 좋은 선택이라고 생각합니다.
다만, 순서 변경 API를 분리할 경우 프론트엔드에서 생성, 수정, 삭제 로직 이후에 순서 변경 API를 동기적으로 호출해야 하므로 처리 과정에서 복잡함이 생길 수 있다고 판단됩니다. (아직 경험이 부족해서 그렇게 느낄 수도 있습니다.)

해당 걱정으로 원하는 방식 (제우스와 동일)

따라서, 가장 간단하고 문제 상황이 적을 것 같은 접근법은 소스 코드 수정과 유사하게 추가, 수정, 삭제를 하나의 API에서 처리 하는 방식이라고 생각합니다.

[Hain-tain]

카테고리를 생성, 수정, 삭제할 때 ordinal 정보를 무조건 프론트에서 줘야한다면 소스코드와 같은 방식으로 api 구현해도 좋을 것 같습니다.

그게 아니고 백에서 ordinal 정보를 생성, 수정할 수 있다면 생성과 삭제는 /categories 로 보내도 괜찮을 것 같아요!

[HoeSeong123]

API 수정사항 (결론) ⚡

카테고리 목록 조회

Response

// before
{
  "categories": [
    {
      "id": 1,
      "name": "Spring"
    }
  ]
}

// after
{
  "categories": [
    {
      "id": 1,
      "name": "Spring",
      "ordinal": 1
    }
  ]
}

카테고리 생성 (템플릿 생성 페이지에서 만드는 요청)

• 이 요청은 그대로 갑니다.

카테고리 생성/수정/삭제 (카테고리 편집 모달에서 보내는 요청)

• 기존 삭제 요청은 사라집니다.
• 아무런 수정이 없는 카테고리도 updateCategories에 담아서 보내주시면 됩니다.

PUT /categories
Content-Type: application/json

{
  "createCategories": [
    {
      "name": "카테고리 1",
      "ordinal": 1
    },
    {
      "name": "카테고리 2",
      "ordinal": 2
    }
  ],
  "updateCategories": [
    {
      "id": 3,
      "name": "카테고리 3",
      "ordinal": 3
    },
    {
      "id": 4,
      "name": "카테고리 4",
      "ordinal": 4
    }
  ],
  "deleteCategoryIds": [5, 6]
}