묘공단 스프링부트 스터디 3주차

 

 

범위 6장

 

API

: 클라이언트의 요청을 서버에 전달하고, 서버의 결과물(응답)을 클라이언트에 잘 돌려주는 역할

(?)@RestController를 말하는 것 ?! 

 

URL ( Uniform Resource Identifier )

 - Uniform : 리소스 식별하는 통일된 방식

 - Resource : 자원, URL로 식별할 수 있는 모든 것 (제한 없음)

 - Identifier: 다른 항목과 구분하는데 필요한 정보

* URL은 Resource(or Representation)만 식별함

 

 

REST API

: 웹의 장점을 최대로 활용하는 API. 자원을 이름으로 구분해서 자원의 상태를 주고받는 API 방식이다.

 - 특징 : 서버/클라이언트 구조, 무상태, 캐시 처리 가능, 계층화, 인터페이스 일관성 

 - 장점: URL만 보고도 어떤 행동을 하는 API인지 명확하게 알 수 있다. 

 - 단점: HTTP메서드 방식의 개수 제한이 있다. 표준 규약이 없다.

 

HTTP 메서드

- GET : 리소스 조회

- POST: 전달할 데이터 처리/ 생성 메서드

=> 조회할 때 POST를 사용할 수 있지만 GET이 캐싱이 가능해서 유리. JSON으로 조회 데이터를 넘겨야 하는 애매한 경우 POST 사용

- PUT: 리소스를 대체(수정)하는 메서드. 리소스가 있으면 덮어쓰고 없으면 새로 생성한다. 부분만 수정하는 것이 안되는 것 같다.

- PATCH : 리소스 일부분을 변경하는 메서드. PATCH를 지원하지 않으면 POST를 사용할 수 있다.

  (GET을 통해서 정보를 받아오고 PUT으로 정보를 수정함에 있어서 GET에서 받은 부분 중 원본+수정본을 같이 보냄으로써 코드의 유연함, 어떠한 field의 수정이 일어났는지 굳이 서버에서 관리를 하지 않을수 있기에 굳이 PATCH보다는 PUT을 사용한다고 할 수 있습니다.

=> patch가 가진 불안정성 ? 

https://www.inflearn.com/questions/93071

)

- DELETE: 리소스 제거

---

있긴 하지만 잘 쓰지 않는 메서드라고 한다.

- HEAD

- OPTION

- CONNECT

- TRACE

 

 

REST API 사용 방법

 - URL에는 동사 사용 x, 자원을 표시 : /getName 과 같이 get, find, delete 등과같은 동사를 사용하면 안된다.

 - 동작은 HTTP 메서드로 표현

 - 계층 관리를 위해 '/'를 사용하고, 마지막은 '/'을 붙이지 않음

 - 가독성을 위해 언더스코어('_')가 아니라 하이픈('-')을 사용

 - 소문자로 쓴다

 - 파일 확장자를 사용하지 않는다.

 - Resource에 대한 정렬, 필터링,  페이징은 신규 api를 생성하지 않고 쿼리 파라미터를 사용한다.

 

프로젝트 파일 구성

- application.yml

- domain

- dto

- repository

- controller

- service

- test

 

 

애노테이션

- @Entity : 엔티티로 지정

- @Id : id 필드를 기본키로 지정

- @GeneratedValue(strategy = GenerationType.IDENTITY) : 기본키를 자동으로 1씩 증가

- @Column(name = "title", nullable = false) : title이라는 not null 컬럼과 매핑

- @Builder : 빌더 패턴으로 객체 생성

- @NoArgsConstructor(access = AccessLevel.PROTECTED)

- @RequestArgsConstructor : final이 붙거나 @NotNull이 붙은 필드의 생성자 추가

- @Service : 빈으로 등록

- @RestController

 

@Controller vs @RestController

- @Controller는 view를 리턴한다. 

- @RestController는 JSON 형태로 객체 테이터를 반환한다.

- Controller에서 데이터를 반환해야 하는 경우도 있다. 이를 위해서는 @ResponseBody 를 붙여서 JSON형태로 보낼 수 있다. 하지만  분리해서 사용하는 것이 좋다. 

 

 

@Builder

생성자에 많은 데이터를 세팅을 해주어야 하도록 설정을 해두었는데 객체를 생성할 때마다 각각 원하는 데이터만 넣어서 세팅을 하고자 한다. 이럴 때에는 생성자에 순서대로 원하는 데이터를 넣어주고 안 넣을 데이터는 null 과 같이 입력을 해주어야 해서 불편하고 보기도 좋지않다. @Builder는 원하는 생성자 데이터들로만 생성할 수 있도록 해주는 패턴이다.

예를들어 이름, 성별, 나이, 주소, 전화번호, 직장, 직장 번호, 재산 등등의 필드를 모두 넣은 생성자에 @Build를 붙이면 이름과 성별만 필요한 생성자에는 이름과 성별 데이터만 순서 구분없이 넣어서 생성할 수 있다. 

애너테이션을 사용하지 않고 빌더패턴을 구현할 수 있지만 많은 코드들을 일일히 구현해줘야한다..

 

컨트롤러 URL 매핑 애너테이션

- @GetMapping

- @PostMapping

- @PutMapping

- @DeleteMapping

 

 

API 구현과정

클라이언트 <-> 컨트롤러 <-> 서비스 <-> 리포지토리

            ( 테스트 코드 )

 

- 클라이언트에서 요청을 보내면 컨트롤러에서는 요청에 대한 HTTP 매서드를 확인하여 URL 매핑 애너테이션이 대응하여 매핑된다.

- @RequestBody가 붙은 객체에 응답에 해당하는 값을 매핑한다.(?)

- 컨트롤러는 요청에 맞는 서비스와 메서드를 호출한다

- 호출된 서비스에서 메서드를 실행한다. -> crud 등의 작업을 실행

- 요청한 자원이 성공적으로 처리되었으면 필요에따라 컨트롤러는 응답을 객체에 담아 전송하거나 상태를 전송한다.

 

?? @RequestBody  vs @PathVariable vs @RequestParam

 

 

테스트 코드

- ObjectMapper : 이 클래스로 만든 객체는 자바 객체를 JSON 데이터로 변환하는 직렬화 또는 반대로 JSON 데이터를 자바에서 사용하기위해 자바 객체로 변환하는 역직렬화를 할 때 사용한다.

- writeValueAsString(): 객체를 JSON으로 직렬화해준다.

- MockMvc: HTTP 메서드, URL, 요청 본문, 요청 타입 등을 설정

- contentType(): 요청을 보낼 때 JSON, XML 등 다양한 타입 중  하나를 골라 요청을 보냄

~~ -> assertThat 등으로 검증

 

 

참고

 

https://junhkang.tistory.com/48

[네트워크] REST, RESTful API의 개념 및 설계 가이드

 

https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP-%EB%A9%94%EC%84%9C%EB%93%9C-%EC%A2%85%EB%A5%98-%ED%86%B5%EC%8B%A0-%EA%B3%BC%EC%A0%95-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC

🌐 HTTP 메서드 종류 & 요청 흐름 💯 총정리

 

https://prohannah.tistory.com/156

RESTful API를 위한 6가지 원칙과 네이밍

https://mangkyu.tistory.com/49

[Spring] @Controller와 @RestController 차이

https://pamyferret.tistory.com/67

빌더 패턴(Builder pattern)을 써야하는 이유, @Builder