여기에서는 원격으로 다른 시스템의 메소드를 콜하는 의미 : 메소드는 서버 측에서 (일부)공개해놓은 메소드만 - 어떻게 처리되는지는 모르나 외부 인터페이스를 통해서 작업을 요청할 수 있음
메소드를 사용하는 이유는 자원(resource)에 대한 핸들링을 하기위해서
REST API의 궁극적인 목표는 클라이언트와 서버의 디펜던시를 없애는 것
독립적인 발전을 위해서 : 서버에 변경이 생겨도 클라이언트는 변경을 하지않아도 됨(완전히 기능을 없애지않는다면…)
유지보수 관점에서도 좋음 : stateless 원칙을 지키고 있다면 서버의 인프라를 확장시킬 때 편함(쿠키와 세션에 대한 고려를 하지않아도 됨
REST 디자인 원칙 중에 오늘 제대로 알게된 것
stateless : 서버에 클라이언트의 컨텍스트를 저장하지않는 것, 그렇다면 쿠키와 세션을 사용하지말라는 것? 맞다. 그렇다면 HTTP의 단점을 그대로 안고 가면 번거로워질텐데? jwt(json web token)을 사용한다는데 이 부분에 대해서 공부해봐야겠다. 알게된 부분만 적자면 jwt는 세션 ID처럼 서버에서 클라이언트를 식별할 수 있도록 값을 가지고 있는데, 세션은 ID를 서버에 저장된 정보를 찾는 용도로 사용하지만(그렇다면 서버에 클라이언트의 컨텍스트를 저장하고 있다는 것) jwt에 있는 값은 암호화된 클라이언트를 식별할 수 있는 값임. 요청을 할 때마다 암호화된 자신의 식별자를 넘기는 것, 바로 든 생각은 그러면 탈취당했을 때는? 그래서 공부를 해야겠다는 것! 알아봅시다!
uniform-interface > HATEOAS : 클라이언트가 어디로 다음 요청을 해야할지 서버가 알려줘야함, 결국 요청지를 정하는 것은 클라이언트인데 메세지(json 메세지 기반)에 다음 요청지가 없다면 HATEOAS 할 수 없음(어플리케이션의 상태 전이는 하이퍼링크를 통해).
테스트
도메인의 코드 중복제거도 중요하지만 테스트 코드 중복제거도 중요함
중복제거는 왜 중요할까? 변경점을 1곳으로 몰아버리기 위해서 다시 말해서 유지보수를 보다 쉽게하기위해서, 모든 것은 비용이다 비용을 낮추는 것이 중요함. 객체지향을 다루면서 변경점이 여러 곳으로 번져버리는 것에 대해 민감하지않으면 어디가서 객체지향 개발자라고 말할 수 있겠는가? 싶음
중복제거를 하는 방법은 어제 TIL에도 적었지만 메소드 뽑기 -> 상속 -> DI 순으로 고민하면서 해결해보기
자바에서 지원하는 기능이 또 한 몫함 : 타입파라미터!(유연한 메소드를 작성할 수 있음)
정리
오늘 하루는 뭔가 많이 하지못한 하루였지만 이전에 했던 내용을 확실하게 다진 하루를 보낸 것 같다. 내일은 또 달려보기!
해야할 것
JPA 내부동작 다시 짚어보기 : 원리부터 본 다음에 사용방법을 봅시다
RestController 인수테스트 작성하기 : 중복 제거까지
토비 스프링 1장 정리
레이어 구조 정리하기 : 어떤 레이어로 나누고 각 레이어 역할, 레이어 간에 인터렉션은 어떻게?