과제 제출 전 고민 해 봐야 할 질문

1. 수정, 삭제 API의 request를 어떤 방식으로 사용하셨나요? (param, query, body)

⇒ body 사용 : 수정 및 삭제 API의 요청 데이터는 @RequestBody를 사용하여 JSON 형식으로 전달하도록 함.

---

2. RESTful 한 API를 설계하셨나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?

-  RESTful 한 부분

1. 리소스 경로 설계

• 리소스 경로는 /api/schedules로 일정을 나타내며, RESTful 한 경로를 설계함

1. HTTP 메서드 사용

• POST /api/schedules: 새로운 일정을 생성
• GET /api/schedules: 모든 일정을 조회
• GET /api/schedules/{id}: 특정 일정을 조회
• PUT /api/schedules/{id}: 특정 일정을 수정
• DELETE /api/schedules/{id}: 특정 일정을 삭제

1. HTTP 상태 코드 사용

• 상태 코드 사용(예: 201 Created, 200 OK, 404 Not Found 등)은 클라이언트에게 요청의 결과를 명확히 전달함

---

- RESTful하지 않은 부분

1. 세부적인 RESTful 요소 부족

• 상태 코드와 함께 더 구체적인 응답 메시지를 제공하지 않을 수 있음
• 예외 처리 및 에러 응답이 자세히 다루어지지 않았음

1. 데이터 검증 및 보안

• 데이터 검증(예: 입력 데이터 유효성 검사)과 보안 조치(예: 비밀번호 해싱 및 보호)가 코드에서 명확히 다루어지지 않음.

---

결론

⇒  기본적인 RESTful 설계 원칙을 따르고 있지만, 몇 가지 추가적인 개선 사항을 통해 더 완전한 RESTful API를 만들 수 있다.

---

3. 적절한 관심사 분리를 적용하셨나요? (Controller, Service, Repository)

1. Controller: HTTP 요청을 처리하고, 클라이언트에게 응답을 반환하는 역할을 잘 수행하고 있으며, 비즈니스 로직을 서비스 계층에 위임하고 있음
2. Service: 비즈니스 로직을 처리하며, 데이터베이스 접근은 리포지토리 계층에 위임하고 있고 데이터 변환 로직도 포함하고 있음
3. Repository: 데이터베이스 접근 로직을 담당하고 있으며, JpaRepository를 통해 기본적인 CRUD 작업을 수행함
4. DTO 및 Request Classes: 데이터 전송 및 요청 데이터를 캡슐화하여 관심사를 분리하고 있음

⇒  따라서  적절한 관심사 분리를 적용하고 있고, 각 계층이 자신의 역할을 충실히 수행하며, 서로의 역할을 침범하지 않는다.

---

4.  API 명세서 작성 가이드라인을 검색하여 직접 작성한 API 명세서와 비교하여 차이점을 설명해 주세요.

⇒ 반환 데이터가 없다. 이 부분은 계속 찾아보고 시도를 하는 중인데 postman을 사용해서 반환 데이터까지 제대로 확인을 했는데 이걸 documentation에서 어떻게 test 반환 결과를 나타내는지 모르겠어서 아직 url 상에서는 반환 결과를 보여주지 못했다. 이 부분에 대해서 추가적인 수정을 위해 계속 알아보는 중이다.