불과 어제 배웠던 REST API가 실무에서는 엄청나게 다르게 쓰이는 걸 배웠다.
과장해서 말하자면 실제로 지키는 곳은 구글 아마존 뭐 이런 초거대 기업 정도라는거 ?
그와 관련해서 새로이 배운 단어는 '페이로드' 와 '멱등성' 특히 멱등성은 단어가 주는 느낌부터 어려운데 한번 실행 했을때 결과와 여러번 실행 했을때 결과가 같아야 한다.
조회 같은 경우 아무리 많이 조회해도 데이터 자체에는 변화가 없으니 멱등성이 유지되는 반면 "1명을 추가해라" 같은 명령은 매번 실행때마다 전체 인원 수가 바뀌기 때문에 멱등성이 유지되지 않는다.
이제 '페이로드'는 실제 전송되는 데이터를 의미한다. JSON의 경우 목적지에서 해석을 위해 여러가지 헤더나 정보들이 들어가는데 이때 전송하기 위한 제일 중요한 데이터가 바로 페이로드이다 택배에서 내용물에 해당한다는 비유가 아주 찰떡
docker에 관해서는 어제 오후에 공부했는데 리눅스 특히 서버측에서 자주 쓰이는 기술이었다.
전체 가상화가 아닌 부분가상화 기술로 서버 관리, 개설등을 획기적으로 간단하게 만들어준
기술. 등장한지 10년도 안됐지만 엄청난 대우를 받는 것이 분명했다.
lombok 또한 어제 겉핥기로 봤던 것보다 더 여러가지 기능이 있는 프레임워크였다. 하지만 코드를 직접 본결과 왜 이때는 쓰고 이때는 안 쓰는지 아직은 모르겠다. 주의점을 잘 알고 써야 한다고 한다.
CI/CD 지속적통합/지속적배포
이건 개발부터 배포 이후 유지까지 지속적이고 발전적인 개발을 의미하는데 이건 꾸준해야 하고 그러기 위해선 자동화가 필요하다 이때 필요한 툴이 젠킨스를 비롯한 자동화 CI툴
깃에 올라와 있는 우리 소스를 살펴봤다. 보면서 느낀점을 나열하자면
adminVO 에서 롬복으로 만든건 기본 생성자??
AllArgsConstructor 과 직접 만든 생성자의 차이 (사수님께 물어봐야한다.)
순서는 내가 했던 파이널 프로젝트와 매우 흡사 했다.
다오에서 정의하고 서비스에서 한번더 써주고 (둘다 인터페이스)
서비스구현클래스에서 다오 싱글톤 객체로 만들어준다음
맵퍼에서 설정했던 기능들 불러와서 쓰는것
이후 컨트롤러에서 서비스 객체 만들어서 사용하는데 이때 반환하는
ResponseEntity<?> 는 처음보는 것
return new ResponseEntity<>(result, HttpStatus.OK);
이렇게 반환하는걸 보니 앞에는 데이터 뒤에는 상태코드에 대한 것을 넘기는 것 같다.
그리고 이런 일련의 과정들이 실제 웹이 아닌 REST에서 이루어지는 걸 보니 rest라는 이름의 프로젝트에서는 기능적 api를 다루는 것 같고 web이라는 이름의 프로젝트 에서는 비기능적 api를 다루는 것 같다.
ResponseEntity를 찾아보면서 다른 기억들도 떠올랐다.
그냥 @controller 만 걸었을때 view값이 필수라서 페이지 전환이 없는 작업은 힘들었다.
이때 써준게 @responsebody 이걸 써주면 해당 메서드에 대해서 view없이 사용했는데
클래스 전체에 그냥 @restcontroller 를 걸어주면 모든 메서드가 view없이 사용가능했다.
이제 이것과 관련해서 가장 섬세한 작업을 가능케 하는게 responseEntity인거 같은데
http 상태코드를 함께 실어서 전송하는것이다 . 이걸 보고 기억나는게
403 에러의 경우 접근 금지를 의미하는 코드라서 해커들이 이것을 보고 페이지의 존재여부를 판단 후에 공격을 할까봐 임의로 404 에러를 송출해서 방어한다는 글을 봤었는데
아마 이런 기술을 써서 구현하는게 아닐까 생각했다.
댓글
댓글 쓰기