3. get board by boardId API
1) getBoard() 메서드
클라이언트로부터 boardId를 입력받아 해당하는 게시글을 반환하고 있다. 만약 DB에 존재하지 않는 boardId인 경우 존재하지 않는 게시글임을 클라이언트에게 알린다.
2) board.getMember() 메서드
Board 테이블은 Member 테이블을 참조한다. 정확히 말하면, 멤버의 Id를 외래키로 가지고 있다. 따라서 board.getMember()는 해당 board에서 참조하는 멤버를 반환한다. 쉽게 말해 게시글의 작성자인 것이다.
3) GetBoardRes
게시글을 조회하려는 클라이언트에게 어떤 정보를 보여주면 좋을까? 게시글의 Id와 작성자의 닉네임, 제목과 내용 정도를 보여주면 될 것 같다. 이를 위해 GetBoardRes라는 DTO를 정의한 것이다. DTO의 필드에 알맞은 값을 생성자 입력으로 넣어 반환하면 된다.
4. delete board API
지금 살펴볼 게시글 삭제 API와 게시글 수정 API에는 각기 다른 로직이 사용되었다. 무슨 말이냐면, 게시글 삭제와 수정을 모두 boardId를 이용해 구현한다면, 중복될 일이 없으므로 매우 편리할 것이다.
다만, 사용자가 게시글의 Id를 알기는 어렵기 때문에 사용자의 편의성을 높이기 위해 게시글의 제목을 입력하여 수정 및 삭제를 할 수 있도록 API를 구현했다.
그러면, 문제가 하나 생길 수 있다. 바로 게시글의 제목은 얼마든지 중복이 가능하다는 것이다. 만약 수정이나 삭제를 요청한 게시글의 제목이 중복되는 경우, 두 가지 선택지가 있을 수 있다.
첫번째는 해당 제목의 게시글을 모두 수정 및 삭제하는 것.
두번째는 중복된 제목이 존재한다는 에러 메시지를 띄우는 것.
이것 또 개발자의 취향이겠지만, 이번 포스팅에서는 수정은 두번째 선택지로, 삭제는 첫번째 선택지로 구현하였다. 즉, 동일한 제목의 게시글에 대해 수정 작업은 진행되지 않고, 삭제 작업은 진행된다.
deleteBoard() 메서드는 아래와 같이 정의되었다.
중복된 제목에 대해 게시글을 모두 삭제해야하기 때문에 List 형태로 delete할 board를 받고 있다. 만약, 존재하지 않는 제목으로 요청했으면, 게시글을 찾을 수 없다는 에러를 내보내고, board들을 찾으면, 순차적으로 삭제 작업을 진행한다.
이전 포스팅에서도 설명한 바 있는데, 실제로 구현할 때에는 반드시 JWT 토큰을 확인하는 로직을 넣어주어야 한다. 왜냐하면, 게시글의 삭제는 게시글의 작성자만 가능해야 하는데, 여기서는 작성자인지 확인하는 로직이 없기 때문이다. 그 말인 즉슨, 누구나 제목만 알고 있으면 지워버릴 수 있다는 뜻이 된다. 그러니 이 점을 반드시 유의해야 할 것이다. JWT 토큰을 확인하는 로직은 아래의 modify board API에 적어 놓겠다.
5. modify board API
1) 요청 파라미터
email은 이메일을, exTitle은 기존 게시글의 제목이고, newTitle은 수정하고자 하는 제목, newContent는 수정하고자 하는 내용이다.
2) JWT 확인 로직
이전 포스팅에 다룬 적 있는 만큼 코드에 대한 설명은 생략하기로 하겠다. 이전 포스팅을 보지 못한 사람들은 아래의 링크를 참조하기 바란다.
여기에 사용된 로직은 사용자 확인이 필수적인 API에 모두 들어가야 한다는 점을 꼭 명심하기 바란다.
3) 게시글 중복 여부 체크
제목으로 게시글을 select한 결과를 List로 만들었다. 이 때 List의 size가 1보다 높다라는 것은 게시글 제목의 중복이 존재한다는 것이다. 이러한 경우에는 수정을 진행하지 않고 에러 메시지를 내보낸다.
오직 List의 size가 1인 경우에만, modifyBoard()메서드가 호출된다.
findById와 getRefernceById의 차이에 대해서도 위 링크의 6-4)에 설명해두었으니 참고하기 바란다. 게시글 수정이 완료되면 게시글 수정이 완료되었다는 Success 메시지가 클라이언트에게 반환된다.
List의 size가 0이면 존재하지 않는 게시글이라는 에러메시지가 전달될 것이다.
지금까지 배운 내용만 활용해도 여러가지 Entity를 만들 수 있고, 연관관계를 매핑할 수 있으며, 다양한 API를 만들어 볼 수 있을 것이다. 다음 포스팅에서는 댓글을 의미하는 Comment 클래스에 대해 Controller와 Repository, Service를 작성해볼 것이다.
그러므로 다음 포스팅을 보기 전에, Comment 테이블은 기존 테이블과 어떤 연관관계를 맺을지, 어떤 API를 정의해야할지에 대해 생각해보기 바란다. 더 나아가 직접 코드를 작성해보고, API를 Postman에서 Test 해보기 바란다.
