foward가 컨트롤러를 두 번 호출하는 것으로 구현이 되어 있다고 한다. 알고나니 당연한 것 같으면서도, 새로웠다.
index는 옛날 정적 페이지만 쓰던 시절 홈(루트)페이지가 목차였기 때문에 사용하던 이름이라 한다.
SpringJPA의 deleteAll은 반복문이다. 진짜 deleteAll은 deleteInBatch이다. 팀원들과 CASCADE에 관해서 얘기하다가 쿼리가 반복 실행된다는 것을 알게됐다. 테이블 정의에 따라 다르겠지만, Delete를 리얼로 하는게 아닌, 플래그로 하여 기존 데이터를 보관해야 하는경우는 deleteAll을 쓸 경우 치명적일 수 있을 것 같다.
REST status code에 관해 좋은 글을 발견했다. https://sanghaklee.tistory.com/61 인데, 특히 애매했던 것이 401, 403, 404에 관한 것이었다. 간단히 얘기해보면 401은 인증, 403은 권한인데 404의 경우는 자원이 존재하지 않는 경우다.
위에서 말한 자원은 영속영역에 존재하는 것 뿐만 아니라, 현재 애플리케이션에서 사용하고 있는 모든 자원을 지칭할 수 있는 것 같다. logout 또한 영속영역은 건드리지 않지만(물론 로그아웃 기록을 DB에 저장하는 등의 작업을 할 수도 있겠지만 논외로 하고) 어쨌든 세션이든 토큰이든 자원을 변경하는 것이기 때문에 GET은 적합하지 않다. GET은 말 그대로 자원을 가져올때 사용한다. 좀 더 엄밀히 생각하면 일종의 없애는 작업이기 때문에 DELETE로 봐야한다는 의견도 봤는데, 파이로와 디온의 멱등성에 관한 글을 보며 다시 생각해봐야겠다.
4xx에러는 대부분 내가 정의하는 에러이기 때문에 메세지를 리턴해도 무방해보인다. 하지만 5xx대 에러는 메세지를 통제해야한다. 중요한 정보를 담고 있을 수 있기 때문이다. 너목들을 하며 컨트롤러에 들어오기 전에 mav를 초기화하며 생기는 에러들을 컨트롤해보니 그냥 getMessage만 리턴해도 꽤 많은 정보(클래스 경로라던지)가 노출됐다. 지금 생각할때 가장 좋은 것은 에러 코드를 추상화하여 보관하고, 리퀘스트 바디만 그대로 되돌려주는게 제일 좋지 않나 하는 생각이다.
JPA 최신 버전에서 특정 DB의 기본키 생성 전략이 table로 바뀌었다고 한다. mysql이 그렇다고하고, h2도 같은 동작을 보였다. 처음에 내가 잘못한줄 알고 삽질을 좀 했었는데, 쿼리 매핑 결과를 보니 id가 전혀 생각하지 않은 값으로 들어가있었다. 앞으로는 명시를 해주는게 좋겠다.