Service
home
WOW Onboarding
home
🧩

[초급 백엔드 스터디 6회차 과제]

들어가기 앞서

이번 스터디에서는 클라이언트의 요청을 받아들이고, 데이터를 응답하는 컨트롤러 계층을 구현해보았습니다.
이로써 드디어! 스프링을 사용한 웹 어플리케이션을 완성했습니다!! 스프링이라는 낯설고 복잡한 도구를 공부하는 과정이 분명 쉽지 않으셨을 텐데 여기까지 따라 오시느라 정말 수고 많으셨습니다.
이번주 과제는 1주차 과제로 직접 작성하셨던 API 명세서에 따라, 컨트롤러 계층을 구현하고 todomate API 서버를 완성하는 것이 과제입니다! (API 명세서와 꼭 일치할 필요는 없어요! 달라져도 괜찮습니다!)
구현하면서 DTO 도 다양하게 만들어보시고, DTO 클래스와 엔티티 클래스 간 변환에 대해서도 고민해보시면 좋을 것 같습니다. (엔티티 → 응답 DTO / 요청 DTO → 엔티티)
혹시 컨트롤러 계층을 더 깊고 자세하게 공부해보고 싶으시다면 인프런에서 김영한 강사님의 스프링 MVC 강의를 수강해보시길 추천드립니다.
또한 이번 스터디에서는 API 에 대한 테스트를 포스트맨으로 직접 진행했는데요, 이 테스트를 자바 코드를 사용하여 진행할 수도 있습니다.
만약 컨트롤러 계층을 ‘단독’ 으로 테스트하여 특정 에러가 발생했을 때 특정 상태 코드와 에러메세지가 담긴 응답이 잘 발생하는지, 에러가 없을 때는 특정 상태 코드와 데이터가 담긴 응답이 잘 발생하는지 테스트하고 싶다면 MockMvc 를 사용한 테스트를 찾아보시길 추천드립니다.
만약 컨트롤러 계층을 포함해서 모든 로직에 대한 통합 테스트를 스프링 부트를 올려서 테스트하는 코드로 작성해보고 싶으시다면 RestAssured 라는 라이브러리를 공부해보시길 추천드립니다.
지난 주까지는 JPA를 사용한 엔티티 클래스 정의, 레포지토리 계층 작성,
어플리케이션 비즈니스 로직을 풀어내는 서비스 계층을 작성했습니다.
혹시 JPA와 관련하여 더 자세히 공부해보고 싶으시다면 김영한 강사님의 JPA 활용 강의와 이론 강의를 들어보시길 추천드립니다.

과제

목표

컨트롤러 계층 작성
포스트맨을 사용하여 API 테스트 해보기

제출해야할 파일과 파일 경로

1.
wil.md (week9 폴더에 넣어주세요)
2.
컨트롤러 계층 완성하기 (아래 폴더 구조 예시 참고, 예시이므로 달라도 괜찮습니다!)
3.
포스트맨 테스트 스크린샷 (성공, 실패)
week9/ └── wil.md └── 포스트맨 테스트 성공/실패 스크린샷 todoapi/ └── main/ └──── java/ └────── com.example.todoapi/ └──────── todo/ └────────── dto/ └──────────── TodoCreateRequest.java └──────────── TodoUpdateRequest.java └──────────── TodoResponse.java └────────── Todo.java └────────── TodoRepository.java └────────── TodoService.java └────────── TodoController.java └──────── member/ └────────── Member.java └────────── MemberRepository.java └────────── MemberService.java └────────── MemberController.java └────── ...
JSON
복사

과제 설명

API 요청을 보낼 때 어떤 형식의 데이터를 보내고, 어떤 형식으로 데이터를 돌려줄 지는 자유롭게 정하셔서 만들어주세요.
이때 로그인 API 의 경우, 로그인에 성공했다면 해당 유저의 PK 값을 응답하도록 해주세요. (member_id, user_id 등)
실제로도 로그인에 성공하면 서버는 클라이언트에게 로그인에 성공한 유저를 식별할 수 있는 데이터를 제공합니다. (이 데이터는 세션 ID 가 될 수도 있고, 토큰이 될 수도 있습니다. 자세한 내용은 ‘스프링 인증’, ‘스프링 로그인 구현’ 과 같은 키워드로 검색해보시면 정보가 많이 나올거에요!)
프론트 입장에서는 로그인에 성공했을 때 서버가 알려준 PK 값을 활용해서 나의 할 일 조회, 생성, 수정, 삭제 요청을 보내고, 나의 친구 리스트를 조회할 겁니다.
혹시 지난주에 미처 고려하지 못한 비즈니스 로직이 있으셨다면, 실제로 todo mate 서비스를 출시한다고 생각하고 다양한 비즈니스 로직을 더 추가해주셔도 좋아요. (ex - 친구가 아닌 유저의 할 일은 조회할 수 없다.)
API 를 완성하셨다면 포스트맨으로 잘 동작하는지 테스트하고, 일부 API 에 대한 테스트 결과를 스크린샷으로 찍어주세요. 어떤 데이터를 담아서 어떤 URL 로 요청을 보냈고, 그 응답은 어떻게 나왔는지 찍어주시면 됩니다! 테스트 결과는 성공한 것 하나와 실패한 것 하나씩 골라서 찍어주세요. 실패의 경우 구현 중 오류에 의한 실패가 아니라, 비즈니스 로직에 의해 의도적으로 실패한 경우를 테스트하고 올려주세요. (존재하지 않는 멤버로 요청, 로그인 실패, 다른 유저의 할 일 조작, 친구가 아닌 유저의 할 일 조회 등)

마감 기한

다음 스터디가 시작하는 11월 13일 수요일 23:59 까지 제출해주세요.

제출 방법