기존 API는 REST API 아키텍쳐를 따르지 않고 주관적으로 만들었기 때문에 url을 그대로 유지하면서 동일한 기능을 만들기에는 무리가 있다고 판단했다. 그래서 최대한 기존 서버가 제공하는 기능을 모두 지원하되 uri는 자원을, HTTP메소드는 자원을 다루는 행위에 집중하여 API를 전체적으로 개편하였다. Member /login POST : 로그인 request login_id password response token /members GET : 회원 리스트 조회 response members POST : 회원가입 request login_id password name nickname

Before before After 변경사항 공통 기존 데이터베이스는 회원 아이디, 책제목등의 값을 PK로 사용하였는데, 이를 각 테이블마다 “테이블명_id”의 대리키를 두어 PK로 사용하도록 변경하였다. Member 기존 DB의 사용자정보를 보관하는 테이블은 아래와 같다. PostgreSQL에서는 Array타입을 허용하고 Django에도 A

기존 코드의 문제점 프로젝트 막바지에 여러 기능들을 급하게 추가하면서 새로운 기능을 보여주는 것에만 초점을 맞추다 보니 request값이 제대로 검증되지도 않고 DB에는 억지스러운 필드가 추가되었다. 결국 최종 데모때 성공적으로 시연하기는 했지만 기대하지 않은 값이 들어오면 바로 오류가 나버리는 위태로운 코드가 만들어졌다. 그리고 더 큰 문제는 시간에 쫒기면서 개발을 하다보니 설계가 엉망이 되었다는 점이다. 처음에는 그래도 잘 설계되고 보기좋은 코드를 작성하려고 노력했지만 시간이 갈수록 지켜지지 못했다. 그래서 이번 기회에 스프링으로 서버를 이전하고 프로젝트를 진행하면서 아쉬웠던 점을 보완하면서 프로젝트 설계 단계부터 깔끔하게 리팩토링을 해보려 한다. 리팩토링 목표 **기존 장고 서버를 스프링으로

시리즈 소개 이번학기 새롭게 진행되는 캡스톤 디자인 과목의 프로젝트 진행과정에 대한 기록을 남기기 위한 시리즈로, 지난번 캡스톤 시리즈(엉박사 시리즈)와는 다르게 개발을 하면서 그때그때 깨달은 점이나 새롭게 학습한 내용들을 정리할 계획이다. 프로젝트를 시작하며 지난번 캡스톤에서는 웹, API, 배포 등에 대한 기초적인 내용을 전혀 모르고 프로젝트에 들어가서 관련된 내용들을 찾는 데에 어려움이 많았다. 또한 다룰줄 아는 프레임워크 또한 유튜브 강의로 익힌 장고가 유일했기 때문에 다른 선택지 없이 장고를 통해 개발을 진행했다. 그 결과 기능구현에만 급급하여 어찌저찌 굴러는 가는 코드가 탄생했다. 그래서 이번에는 좀 더 준비된 상태에서 프로젝트를 시작하기 위해서 겨울방학동안 인프런에서 김영한 강사님의 스프링강의 로드맵을 타면서 객체지향과 JPA, 스프링 프레임워크에 대한 이해를 높였다. 또한 이전 프로젝트의