대바보의 끄적끄적

스프링 웹 개발 기초

1. 정적 컨텐츠

서버에서 파일을 웹브라우저에 그냥 내려준다.

resources 경로 안에 static, public안에 html은 스프링 부트에서 자동으로 올려준다.

/hello-spring/src/main/resources/static 경로 안 파일 확인

-rw-r--r--  1 mac  staff  222  8  9 14:10 hello-static.html

-rw-r--r--  1 mac  staff  227  8  9 10:52 index.html

정적컨텐츠 가져오는 순서

클라이언트 요청 -> 컨트롤러 체크(우선순위는 컨트롤러) -> 없을 경우 static, public 경로 파일 있는지 확인

2.MVC와 템플릿 엔진

Model View Controller

View : 화면을 그리는데 집중해야 한다.

Model, Controller : 비지니스 로직에 집중한다.

Code

@GetMapping("hello-mvc")

public String helloMvc(@RequestParam(value = "name") String name, Model model){

    model.addAttribute("name",name);

    return "hello-template";

}

3.API

View를 사용하지 않고 데이터를 바로 내릴 수 있다.

@ResponseBody를 사용할 경우 viewResolver 대신 httpMessageConverter가 동작한다.

기본 문자 처리

StringMessageConverter

기본 객체 처리

MappingJackson2 MessageConverter

요새는 보통 json형태로 데이터를 제공해준다.

Ex)

{

"name": "test"

}

Code

@GetMapping("hello-string")

@ResponseBody

public String helloString(@RequestParam(value = "name") String name, Model model){

    return "hello "+name;

}

클라이언트에 서버로 데이터 전송

주로 GET에선 쿼리 파라미터로 전송한다.

body도 되긴 하나 잘 사용하지 않는다.

POST, PUT, PATCH에선 HTTP 메시지 body로 보낸다.

정적 데이터 조회

- GET을 사용한다.

- 쿼리 파라미터를 사용하지 않는다.

- 이미지를 가져올 때 사용한다.

동적 데이터 조회

- GET을 사용한다.

- 쿼리 파라미터를 기반으로 결과를 동적으로 생성

- 검색어 = 필터 라한다.

HTML FORM 전송

- POST를 사용한다.

- 웹 브라우저가 FORM데이터를 읽어 HTTP 메시지를 생성해준다.

- Content-Type : application/x-www-form-urlencoded

- HTTP 메시지 바디에 담아 서버로 보낸다.

- GET으로 변경도 가능하나 데이터 변경 작업이 있으면 사용하면 안 된다.(조회에서 사용 가능)

HTML FORM 데이터 전송

- multipart/form-data

- form에 파일을 담아 보낼 때 사용한다.

- 파일만 가는 게 아니라 form데이터 전체를 보낸다.

- Content-Type: multipart/form-data;boundary=123

- 바운더리로 구분한다.

HTTP API 전송

- 서버 TO 서버

- 앱 클라이언트

- 웹 클라이언트(ajax, React, Vue)

- GET, POST, PUT, PATCH 다 사용 가능하다.

- Content-Type : application/json을 주로 사용한다.

HTTP API 설계 예시

리소스 기반(/members)으로 설계한다.

[

회원 목록 /members -> GET

회원 등록 /members -> POST

회원 조회 /members/{id} -> GET

회원 수정 /members/{id} -> PATCH, PUT, POST

회원 삭제 /members/{id} -> DELETE

]

HTTP API - 컬렉션

(서버가 관리하는 리소스 디렉터리)

- POST 기반 등록

POST로 등록할 시 등록될 URI정보를 모른다.

서버에서 RESPONSE에 Location을 담아준다.

즉, 서버에 요청해 서버가 정해준다.

HTTP API - 스토어

(클라이언트가 관리하는 리소스 저장소)

- PUT 기반 등록

클라이언트가 직접 리소소의 URI를 지정한다.

클라이언트에서 서버에 원격으로 데이터를 넣을 때 사용한다.

클라이언트가 파일 이름을 알고 있고 파일을 업로드할 때 사용한다.

POST, PUT 중에선 주로 POST를 사용한다.

HTTP FORM 사용

GET, POST만 지원한다.

컨트롤 URI를 사용한다. ex) /members/{id}/delete

FORM은 GET,POST만 지원해 제약이 있다.

제약을 해결하기 위해 동사로 된 리소스 경로를 사용한다.

/members/{id}/delete

좋은 URI 설계 개념

문서

- 단일 개념(파일 하나, 객체 하나)

-/members/100

컬렉션

- 서버가 관리하는 리소스 디렉터리

- 서버가 리소스의 URI를 생성하고 관리

스토어

- 클라이언트가 관리하는 자원 저장소

- 클라이언트가 리소스의 URI를 알고 관리

컨트롤러, 컨트롤 URI

- 문서, 컬렉션, 스토러로 해결하기 어려운 추가 프로세스 실행

- GET, POST, PUT, PATCH만으로.

- /members/{id}/delete

http 메서드

http api 설계 방법

회원 정보 관리 API를 만들어라.

리소스 기반으로 설계해야 한다.

회원이라는 개념이 리소스이다.

/members <-회원 개념 리소스

회원 목록 조회 /members

회원 조회 /members/{id}

회원 등록 /members/{id}

회원 수정 /members/{id}

회원 삭제 /members/{id}

리소스와 행위를 분리한다.

행위란? 조회, 등록, 삭제, 변경

조회, 등록, 수정, 삭제가 다 /members/{id} 이렇게 사용할 때

여러 http메서드를 사용한다.

즉, 행위는 http 메서드로 구분한다.

http 메서드 종류

GET : 리소스 조회

POST : 요청 데이터 처리, 주로 등록에 사용

PUT : 리소스를 대체, 해당 리소스가 없으면 생성

PATCH : 리소스 부분 변경

DELETE : 리소스 삭제

HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환

OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)

CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정

TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

자주 쓰는 메서드

GET

1. 리소스 조회

2. 서버에 전달하고 싶은 데이터는 query를 통해서 전달

3. 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.

POST

1. 요청 데이터 처리

2. 메시지 바디를 통해 서버로 요청 데이터 전달

3. 서버는 요청 데이터를 처리

- 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.

4. 주로 전달된 데이터로 신규 시로스 등록, 프로세서 처리에 사용

**메시지 바디를 통해 들어온 데이터를 처리한다.

**신규 데이터 등록 등에 사용한다.

POST로 보내면 저장하기로 서버와 약속한다.

# 서버에 요청 Request

POST /members

{

“userName”:”choi”,

“age”:20

}

# 서버의 응답 Response

HTTP/1.1 201 Created

Content-Type:application/json

Content-Length:34

Location:/members/100

{

“userName”:”choi”,

“age”:20

}

요청 데이터를 처리한다는 것은 무슨 뜻 일까?

대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청합니다.

예제 )

1.FORM데이터 처리

2. 게시판 글쓰기 댓글 달기

3. 서버가 아직 식별하지 않은 새 리소스 생성

4. 기존 자원에 데이터 추가

딱 정해진 것은 아니고 정하기 나름이다.

1. 새 리소스 생성

2. 요청 데이터 처리(서버에서 변화가 일어남)

3. 값 하나를 바꾸는 것이 아닌 프로세스 상태 변경에서 사용됨

4. 컨트롤 URI에 사용된다.

5. 다른 메서드로 처리하기 애매하면 POST를 사용한다.

PUT

1. 리소스를 완전 대체

- 리소스가 있으면 대체

- 리소스가 없으면 생성

- 쉽게 이야기해서 덮어버림

2. 클라이언트가 리소스 위치를 알고 URI 지정

- 클라이언트가 리소스 위치를 알고 URI 지정

- /members/100

3. 값을 대체하기에 하나의 값만 변경할 수 없다.

PATCH

1. 리소스 부분 변경

- 업데이트라고 생각하면 된다.

2. 서버에서 PATCH를 사용하지 못하면 POST를 사용한다.

DELETE

1. 리소스 제거

- 삭제

HTTP 메서드의 속성

1. 안전(Safe Methods)

2. 멱등(Idempotent Methods)

3. 캐시 가능(Cacheable Methods)

1. 안전

-호출해도 리소스를 변경하지 않는다.

-데이터가 변경 없는 메서드(GET, HEAD)

2. 멱등

-한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.

-GET,PUT,DELETE

-POST는 벽등이 아니다. 주문 시 계속 주문된다.

-똑같은 요청을 두 번 해도 괜찮다

3. 캐시 가능

- 응답 결과 리소스를 캐시 해서 사용해도 되는가?

- 스펙상 GET, HEAD, POST, PATCH 캐시 가능

- 실제로는 GET, HEAD 정도만 캐시로 사용

- POST, PATCH는는 바디 까지 캐시 키로고려해야하 하는데, 구현이 쉽지 않다.