SpringBoot란? - 김지영
스프링부트(Spring Boot)는 자바의 웹 프레임워크로 기존 스프링(Spring) 프레임워크에 톰캣 서버를 내장하고 여러 편의 기능들을 추가하여 꾸준한 인기를 누리고 있는 프레임워크이다.
제어의 역전 (Inversion Of Control, IoC)
IoC를 적용한 환경에서는 사용할 객체를 직접 생성하지 않고 객체의 생명주기 관리를 외부에 위임합니다. 여기서 '외부'는 스프링 컨테이너 또는 Ioc컨테이너를 의미합니다.객체의 관리를 컨테이너에 맡겨 제어권이 넘어간 것을 제어 역전이라고 부르며 제어 역전을 통해 의존성 주입(DI;Dependency Injection), 관점 지향 프로그래밍(AOP;Aspect-Oriented Programming)등이 가능해집니다.
스프링을 사용하면 객체의 제어권을 컨테이너로 넘기기 때문에 개발자는 비즈니스 로직을 작성하는 데 더 집중할 수 있습니다.
의존성 주입(DI)
의존성 주입(DI:Dependency Injection)이란 제어 역전의 방법 중 하나로 사용할 객체를 직접 생성하지 않고 외부 컨테이너가 생성한 객체를 주입받아 사용하는 방식을 의미합니다.
스프링에서 의존성을 주입받는 방법은 세 가지가 있습니다.
•
생성자를 통한 의존성 주입
•
필드 객체 선언을 통한 의존성 주입
•
setter 메서드를 통한 의존성 주입
스프링에서는 @Autowired라는 어노테이션을 통해 의존성을 주입할 수 있습니다. 스프링 4.3 이후 버전 생성자를 통해 의존성을 주입할 때 @Autowired 어노테이션을 생략할 수도 있습니다.
@RestController
public class DIController {
MyService myService;
@Autowired
public DIController(MyService myService){
this.myService = myService;
}
@GetMapping("/di/hello")
public String getHello(){
return myService.getHello();
}
Java
복사
권장하는 의존성 주입 방법은 생성자를 통해 의존성을 주입받는 방식입니다. 다른 방식과는 다르게 생성자를 통해 의존성을 주입받는 방식은 레퍼런스 객체 없이는 객체를 초기화할 수 없게 설계할 수 있기 때문입니다.
관점 지향 프로그래밍(AOP)
AOP는 관점을 기준으로 묶어 개발하는 방식을 의미합니다. 이러한 AOP를 구현하는 방법은 크게 세가지 있습니다.
•
컴파일 과정에 삽입하는 방식
•
바이트코드를 메모리에 로드하는 과정에 삽입하는 방식
•
프락시 패턴을 이용한 방식
스프링AOP의 목적은 OOP와 마찬가지로 모듈화해서 재사용 가능한 구성을 만드는 것이고 모듈화된 객체를 편하게 적용할 수 있게 함으로써 개발자가 비즈니스 로직을 구현하는 데만 집중할 수 있게 도와주는 것입니다.
스프링 프레임 워크 vs 스프링 부트
1.
의존성 관리(스프링 부트는 의존성을 제공합니다.)
2.
자동 설정(애플리케이션에 추가된 라이브러리를 실행하는 데 필요한 환경 설정을 알아서 찾아줍니다.)
3.
내장 WAS(스프링부트는 내장 WAS가 존재합니다. 자동 설정 기능은 톰캣에도 적용되므로 특별한 설정 없이도 톰캣을 실행할 수 있습니다.)
REST란?
HTTP를 잘사용하기 위한 아키텍쳐(제약조건들의 집합) 스타일이다.REST는 URI와 HTTP 메소드를 사용해서 자원과 행위를 표현합니다.REST의 원칙을 지키면서 API의 의미를 표현하고 쉽고 파악하기 쉽게 하는 것을 RESTful하다고 합니다.
REST API란?
REST한 방식으로 데이터를 상호교환하게 설계된 API를 말합니다.
=>HTTP를 잘사용하기 위해 URI와 HTTP메소드를 사용해서 URI로 어떤 자원에 접근할 것인지, 메소드로 어떤 행위를 할 것인지 표현하여 설계된 API를 말합니다.
•
>API가 RESTful로 간주되기 위해서는 몇가지 조건이 있는데 그 중 가장 중요한 건 클라이언트와 서버가 종속적이지 않아야한다는 말입니다. 즉, 클라이언트가 요청시마다 자기정보를 보내야하고 서버는 받은 정보로 클라이언트의 정보를 확인합니다.
RESTful API를 사용하면 좋은점
URL만 보고 어떤 자원에 접근할 것인지 메소드를 보고 어떤 행위를 할지 알 수 있기 때문에 개발을 할 때 용이합니다.
Controller 생성
@RestController
public class HelloController {
@RequestMapping(value = "/hello", method = RequestMethod.GET)
public String hello(){
return "Hello World";
}
}
Java
복사
PathVariable
@RequestMapping(value = "/variable1/{variable}")
public String getVariable1(@PathVariable String variable) {
return variable;
}
Java
복사
HTTP 메소드 - 김희정
•
Uniform Resource Identifier, 리소스를 식별하는 방식
•
URI는 로케이터(locator, URL), 이름(name, URN) 또는 둘 다 추가로 분류될 수 있다.
•
URL : 리소스가 있는 위치 지정 >> 주로 URN보단 URL을 주로 사용
API URI 설계 예시
•
회원 목록 조회 /members
•
회원 조회 /members/{id}
•
회원 등록 /members/{id}
•
회원 수정 /members/{id}
•
회원 삭제 /members/{id}
•
URL에서는 행위(동사)가 아닌 결과,리소스(명사)를 포함한다.
•
행위는 HTTP 메소드로 구분!
HTTP(HyperText Transfer Protocol)
•
클라이언트 서버 구조
•
HTTP 메시지에 모든 것을 전송
메서드
행위는 HTTP 메소드로 구분!
Create : POST
Read : GET
Update : PUT
Delete : DELETE
GET
•
리소스 조회
◦
ex) 회원 조회 /members/{id}
•
서버에 전달하고 싶은 데이터를 query 통해 전달
•
ex) GET /search?q=hello&hl=ko HTTP/1.1
POST
•
요청 데이터 처리, 주로 등록에 사용
•
메시지 바디를 통해 서버로 요청 데이터 전달 >> 서버는 요청 데이터 처리(신규 리소스 등록, 프로세스 처리)
•
기능
1.
새 리소스 생성
- ex) 신규 주문 생성, 회원 등록
2.
요청 데이터 처리
•
프로세스 처리
◦
단순한 값 변경이 아닌 프로세스 상태 변경일 경우
◦
ex) 결제완료 -> 배달시작
◦
컨트롤 URL : POST /orders/{orderId}/start-delivery
3.
다른 메서드로 처리하기 애매한 경우
•
JSON 넘겨야 되는데, GET 사용하기 어려운 경우
GET과 POST의 차이
1.
가장 큰 차이점은 HTTP 요청을 할 때 파라미터를 path나 쿼리파라미터를 쓰지 않고 Request Body에 보낸다.
2.
주로 회원가입 등 Http전송 중 노출되면 안되는 정보를 보낼 때 Post를 쓴다.
PUT
•
리소스 완전 대체 : 덮어쓰기
◦
리소스가 존재하면 않으면? : 새로운 자원으로 생성
◦
리소스가 존재하면? : 완전 대체, 일부 필드값이 없다면 null로 변경됨.
PUT과 POST의 차이
put은 멱등하지만 post는 멱등하지 않다.
>>멱등하다 : 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
POST : 같은 요청을 여러번 하면 각기 다른 결과 생성한다.
PATCH
•
리소스 부분 변경
◦
ex) member의 age 필드만 변경
DELETE
•
리소스 제거
스프링 부트 주요 어노테이션, HTTP 메소드와 상태코드 - 이현주 작성
스프링 부트 주요 어노테이션
1. Annotation
•
사전적 의미로 주석을 뜻한다. 자바에서는 코드 사이에 주석처럼 사용되며 특별한 의미나 기능을 수행하도록 하는 기술을 말한다.
•
즉, 프로그램에게 추가 정보를 제공해주는 메타 데이터(데이터를 위한 데이터)라고 볼 수 있다.
•
코드 양이 줄고 유지 보수가 용이하며 생산성이 증가되는 장점이 있다.
@Component
•
클래스를 bean으로 등록할 때 사용하는 어노테이션****
@ComponentScan ?
•
스프링 프레임워크가 @Component, @Service, @Repository, @Controller, @Configuration 중 어느 어노테이션이라도 붙은 클래스가 있으면 컨텍스트Context에 bean으로 등록한다.
@Bean
•
개발자가 제어할 수 없는 외부 라이브러리와 같은 것들을 bean으로 만들 때 사용하는 어노테이션
@Controller
•
스프링에게 해당 클래스가 컨트롤러 역할을 한다고 명시하기 위해 사용하는 어노테이션
@RequestHeader
•
요청Request의 헤더Header 값을 가져올 수 있다. 메소드의 파라미터에서 사용되는 어노테이션
@RequestMapping
•
사용 방식
◦
@RequestMapping(value = “ “)
◦
요청Request으로 들어온 URI와 어노테이션 value 값이 일치하면 해당 클래스 혹은 메소드가 실행됨
◦
컨트롤러 객체 안의 클래스, 메소드에 모두 적용 가능
◦
해당 어노테이션을 클래스 단위에서 사용하면 하위 메소드에 모두 적용됨
◦
메소드에 적용되면 해당 메소드에서 지정한 방식으로 URI를 처리함
@RequestParam
•
URL에 전달된 파라미터를 받아 처리할 수 있도록 메소드 인자와 매칭시키는 역할을 하는 어노테이션
•
Json 형식의 Body를 MessageConverter를 통해 자바 객체로 변환시킨다.
@RequestBody
•
Body에 전달되는 데이터를 받아서 처리할 수 있도록 메소드 인자와 매칭시키는 역할을 하는 어노테이션
•
클라이언트가 보내는 HTTP 요청 본문 (Json, xml 등)을 자바 객체로 변환한다.
@ModelAttribute
•
클라이언트가 전송한 HTTP 파라미터, Body 내용 등의 데이터를 Setter 함수를 통해 1:1로 객체에 연결한다.
•
Json 데이터를 받는 @RequestBody와 달리 @ModelAttribute은 Json을 처리할 수 없음
@ResponseBody
•
메소드의 리턴 값이 View로 출력되지 않고 HTTP Response Body에 직접 쓰이도록 하는 어노테이션
•
json, xml과 같은 데이터를 반환함
@Autowired
•
스프링 프레임워크에서 Bean 객체를 주입하기 위한 방법 중 하나이다.
•
스프링 프레임워크에서 클래스를 보고 타입에 맞게 Bean을 주입한다.
@GetMapping
•
== @RequestMapping(Method = RequestMethod.GET)
@PostMapping
•
== RequestMapping(Method = RequestMethod.POST)
@SpringBootTest
•
스프링 부트 테스트에 필요한 의존성을 제공하는 어노테이션
2. Lombok 어노테이션
@Setter
클래스 내 모든 필드의 setter 메소드를 생성
@AllArgsConstructor
클래스 내 모든 필드 값을 파라미터로 받는 생성자를 추가
@NoArgsConstructor
클래스 기본 생성자를 추가
@ToString
클래스 내 모든 필드에 대해 toString 메소드를 생성
HTTP
1. HTTP 메서드
클라이언트가 웹 서버에 사용자 요청의 목적, 종류를 알리는 수단.
자주 사용되는 메소드 (5개)
구분 | 특징 | 설명 |
GET | 리소스 조회 | 보통 리소스 조회 시 많이 사용한다. |
클라이언트에서 서버로 데이터를 전송할 경우 GET 메소드는 쿼리 파라미터를 데이터 전송이 이루어진다. | ||
메세지 바디를 사용하여 데이터를 전달할 수 있기는 하지만, 지원하지 않는 곳이 많아 권장하지 않는다. | ||
POST | 요청 데이터를 처리 | |
주로 데이터 등록 시 사용 | 데이터 요청을 처리하고 메시지 바디를 통해 데이터를 서버로 전달. | |
주로 신규 리소스를 등록, 프로세스 처리에 사용되는 메소드 | ||
PUT | 리소스를 대체 | |
해당 리소스가 없으면 생성 | 리소스가 있으면 대체하고(덮어쓰고) | |
리소스가 없을 경우 새로 생성한다. | ||
PATCH | 리소스 일부를 변경 | PUT처럼 리소스 수정 시 사용하나, |
PATCH는 리소스 일부만 변경 가능 | ||
DELETE | 리소스 삭제 | 리소스 제거할 때 사용 |
2. HTTP 상태코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
상태코드표
상태코드 | 의미 |
1xx(Informational) | 요청이 수신되어 처리중 |
2xx(Successful) | 요청 정상 처리 (= 성공!) |
3xx(Redirection) | 요청을 완료하려면 추가 행동이 필요 |
4xx(Client Error) | 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음. |
5xx(Server Error) | 서버 오류, 서버가 정상 요청을 처리하지 못함 |
