외부에 제공하는 api

오픈 api처럼 외부에 api를 제공하고, api 명세서 제공한다.
이경우 api의 스팩이 정해져있고 다양한 clientem들이 이 규칙에 따라서 호출하게된다.
api는 성공하는경우가 대부분이겠지만 상황에 따라서 실패하기도 하고 이에따라 실패 메시지를 받게된다.
실패에도 다양한 경우가 있다.

이포스트는 여러가지 실패한 상황과 예외에 대해 다뤄보려고한다

주로 문법과 활용방법에관해 다루는 포스트이다.

• try-catch-final
• throw, throws
• checked, unchecked exception
• custom exception

예외란?

프로그램의 동작이 정상적인 처리 범주에서 벗어난 경우 “ 예외(Exception)가 발생했다.” 라고 말한다. 예상하지 못한 사건의 발생이라고 볼 수 있다. 예외는 언제 발생하고 우리는 어떤 마음가짐으로 대해야할까?

${}, #{}

mybatis mapper에서 parameter를 받아서 사용할때 크게 2가지 방법이 있다.
${}, #{} 두가지 방법은 동작이 다르고 경우에따라서는 보안상으로 좋지 않으므로 차이점을 명확히 알고 사용해야한다.

• ${} : 원문 그대로 -> 잠재적 sql injection 취약점 - 주의해서 사용
• #{} : ' ' 를 씌워줌, sql injection 방지

chrome80

크롬 80버전부터 새로운 쿠키 정책(SameSite Cookie)이 시행될 예정이다.
이 정책이 시작되면 어떤 영향도가있는지, 어떻게 대응해야할지 알아보자

바뀐 쿠키정책

목적

CSRF ( cross-site-request-forger ) 공격을 막기 위해 third-party 쿠키를 막으려는것이 기본 컨셉이다. 이를 위해 cookie 정책중 samesite의 기본값을 바꾼다. 하지만 이렇게되면 오류가 매우 많이 발생할수 있으니 top-level navigation일 경우에는 third-party cookie를 허용해주는 Lax를 기본값으로 한다.
chrome79 에서는 samesite 기본값이 None으로 되어있으나 chrome80 부터는 Lax가 된다.

웹서비스를 하다보면 데이터를 조회하고, 그데이터를 일괄 다운로드하는 니즈가 생긴다.(특히 어드민)
이런경우 서버 성능에따라 oom(out of memory)이 발생할 수 있다.
자주 생기는 상황으로는 대량의 데이터를 조회한 다음, 이를 엑셀파일로 내려받는경우가 있다.
이 경우를 예시로 원인과 해결법을 알아보고자 한다.

원인

1. db에서 데이터를 가지고와서 객체로 들고있는 단계에서 OOM
2. workbook을 생성해 데이터체우다가 OOM
3. 메모리에 담고있는것을 전송하는 단계까지 메모리를 계속 holding! - OOM 확률 up!

개선포인트

A. db에서 한번에 가지고오는 데이터 크기(fetch size)를 조절한다
B. db에서 가지고온 데이터를 통체로 들고있지 않고 나누어 처리한다.
C. 엑셀에 내용을 체우다가 일정 사이즈 이상 되면 Disk에 쓰도록 한다 (기존에도 되어있음)
D. 임시파일은 바로바로 삭제하도록한다 (삭제를 명시적으로 하지 않으면 tomcat 내려갈때 삭제됨. 강제종료시는 삭제 안될 가능성)
E. 다운로드 중복클릭 방지