API 문서를 정리하면서....
우리는 swagger나 restdocs 같은 자동화 api 문서툴을 사용하지 않기 때문에 구글 스프레드 시트에 직접 만들고 있다. 그나마도 정형화 되지않은 형식 + 대충 기입하는 req, res 때문에 조금 난항을 겪고있는데 .... 그걸 조금은 정리하려고 하다보니 사용자 지정함수나 기존 시트의 함수에 대해서 알게되고 좀 재미를 느끼고 있다. 엑셀도 결국 간단한 수식으로 보니까 메서드랑 다를게 없네 라는 생각. 전혀 개발적인 내용은 아니지만 오늘 새로이 알게돼서 재밌는 점.
1. http 메소드 put과 patch
put: 리소스를 전부 업데이트
patch: 리소스의 일부만 업데이트
즉 put 에서 일부 데이터만 보낸다면 보내지 않은 값에 대해서는 null이 입력되는 것과 같다. (실제로는 구현하기 나름이지만 이런 방향성을 가지고 구현하는 것이 좋다.)
put은 엔티티를 전송한다는 느낌으로 기존의 값이 없다면 생성도 된다.
2. 웹브라우저 주소 입력 후 이뤄지는 과정
- 주소창에 URL 입력
- 웹브라우저(chrome, IE ...)가 URL을 해석 한다. scheme: // user:password@host[:port][/]path[?query][#fragment]
- 일반적으로 url형식에 맞지 않는다면 "검색"으로
- 형식에 맞는다면 HSTS 목록을 로드해서 확인한다. (https or http)
- DNS 조회해서 IP를 이용해 접속한다.
- 해당 웹서버는 요청받은 파일과 파라미터값을 이용해 결과를 웹브라우저에 다시 전달하고 웹브라우저는 결과를 해석해서 사용자에게 보여준다.
3. 객체 지향설계 (+ SOLID 원칙)
객체지향은 4대특성을 가진다.
캡슐화 - 데이터구조와 데이터를 다루는 방법(기능)을 결합시킨다. 외부로 부터 접근을 통제하는 것도 의미한다.
상속 - 상위개념의 특징을 하위 개념이 물려받는다. 재사용 + 확장
추상화 - 객체들의 공통적인 특징(속성과 기능)을 뽑아내는것이다. 모델링을 의미한다.
다형성 - 오버라이딩과 오버로딩을 의미한다. 메소드를 재정의 하고 사용편의성을 늘린다.
이런 특징들을 가진 객체지향설계의 5대 원칙은 아래와 같다.
SRP (단일 책임 원칙) - 클래스의 역할과 책임을 제한해라. 속성, 메서드, 패키지, 모듈, 컴포넌트 까지 단일책임을 주고 독립적으로 만들어라. 추상화와 관련있다.
OCP (개방 폐쇄 원칙) - 자신의 확장에는 열려있고, 주변의 변화에 대해서는 닫혀있어야 한다. 결합도를 낮추고 인터페이스를 중간에 두어 직접적 연동을 피하자.
LSP (리스코프 치환 원칙) - 상속관계에서 하위 클래스는 상위클래스의 분류이다. 즉 하위클래스가 상위클래스 역할을 대신할 때 논리적으로 맞아 떨어져야 한다.
ISP (인터페이스 분리 원칙) - 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안된다. 인터페이스로 메소드를 분리해주자.
DIP (의존 역전 원칙) - 추상적인 클래스는 구체적인 클래스에 의존해선 안된다. 이것은 아래의 의존성 주입, 제어역전에서 추가로 알아보자.
4. 의존성 주입(Dependency Injection), 제어 역전(Inversion of Control)
의존성주입이라는것을 사용하면서도 용어자체의 낯설음 때문에 항상 이에 대한 대답이나, 설명이 애매한 그런 부분이 있었다.
의존성 주입은 프로그램 디자인의 결합도를 낮추고, 재사용성을 올린다.
(이건 일반적으로 의존성 주입을 검색했을 때 나오는 결과이다. 여러 포스팅을 찾아본결과 쉽게 말하자면 대충 이렇다.) 의존성 주입은 NEW 를 사용해서 객체를 "생성" 하는것이 아니라 프로그램에 생성을 부탁하고 그냥 "빌려"쓰는 것이다. 의존성을 외부로 돌림으로 해당 객체가 변했을 때도 사용하는 곳에서 크게 신경쓸 필요가 없다.
제어역전은 의존성주입보다 더 일반적인(상위의) 개념으로 스프링 컨테이너가 bean들을 대신 제어(관리) 해주는걸 의미한다. 생성과 의존성설정, 초기화와 마지막 소멸까지 객체에 대한 제어권이 개발자에서 컨테이너로 역전되기 때문에 이와같은 명칭을 사용하며 의존성 주입과 비슷한 장점을 얻을 수 있다. 애플리케이션 컨텍스트(빈팩토리의 확장)이 IoC를 적용해서 관리해야 하는 모든오브젝트를 관리한다.
4-1) 의존성 주입의 3가지 방법
⒜ 필드주입 - 스프링에 존재하는 방법으로 수정자(setter)를 통한 주입과 유사한 방식으로 이루어 진다. 가장 쉬운방법으로 의존성주입을 마구 추가할 수 있으나 final을 선언할 수 없어서 불변성을 지니지 못하며, 순환참조의 위험성이 존재한다.
⒝ 수정자주입 - set 메서드에 @Autowired 달아줘서 의존성을 주입합니다. 주입여부와 관계없이 객체가 생성되므로 nullpoint 발생 가능성
⒞ 생성자주입 - 현재 가장 권장되는 방법으로 필드/수정자 주입으로 생길 수 있는 문제들을 해결할 수 있다. 단점은 매개변수가 다른 경우의 생성자를 작성해주는것이 번거롭다는 점이있지만, 요즘에는 롬복의 어노테이션을 이용하여 간단하게 생성자를 작성할 수 있다. (이 중 "테스트코드 작성에 용이하다" 라는 장점은 아직 파악하지 못했다... 무슨말인지 원)
5. Spring 과 Spring Boot
스프링은 자바 플랫폼을 위한 오픈소스 애플리케이션 프레임워크로 크게 세가지 목적을 가지고 사용한다. 의존성 주입, 중복된 코드제거, 다른 프레임워크와의 통합. 이외의 장점은 AOP(관점지향프로그래밍)사용으로 기존비즈니스 로직수정 없이 기능적추가를 할 수있다는 점이나 ORM과의 우수한 통합환경을 제공한다는 점이 있다.
spring의 큰 단점은 바로 "설정이 너무 어렵다". 수많은 의존성주입과 버전 매치업, xml 파일을 이용해서 하나하나 설정해줘야 함은 큰 진입장벽이 되었고, 이를 극복하고자 SpringBoot가 나왔다. 목적은 쉬운(자동)설정 또 내장서버를 지니고 있다는 차이점이 있다. boot는 홈페이지에서 강조하는 문구로 'just run'을 강조하며 starter 의존성 하나로 spring에서 관리해야 했던 수많은 의존성을 추가할 수 있다.
기존 스프링 환경을 사용하는 분들중 부트로 넘어가지 않는 경우는 1. 대규모 트래픽에 대한 불화실성 2. 자동화 설정에 관한 불확실성 이라는데 아마 설정을 기가막히게 잘해서 spring을 사용하는데 어려움이 없다면 그럴 수 있다고 생각된다.
6. http 와 https
보안계층의 추가 (TLS, SSL) - 암호화, 인증, 변경감지 등
7. REST API
댓글
댓글 쓰기