New 병아리 개발자

# HTTP 메서드

## HTTP API 생성

• 요구사항 : 회원 정보 관리 API 생성 (회원 목록 조회 / 회원 조회 / 회원 등록 / 회원 수정 / 회원 삭제)

API URI 설계 (Uniform Resource Identifier)

회원 목록 조회 : /read-member-list
회원 조회 : /read-member-by-id
회원 등록 : /create-member
회원 수정 : /update-member
회원 삭제 : /delete-member

• 과연, 이건 좋은 URI 설계일까?
• URI 설계의 가장 중요한 건 '리소스 식별' 이다.

리소스의 의미?

회원을 등록하고 수정하고 조회하는게 리소스가 아니다.

예를 들어미네랄을 캐라에서 리소스는 미네랄. (즉, 회원이라는 개념 자체가 바로 리소스)

리소스를 어떻게 식별?

회원을 등록하고 수정하고 조회하는 것을 모두 배제.

회원이라는 리소스만식별하면 됨. (회원 리소스를 URI에 매핑)

API URI 설계 (리소스 식별, URI 계층 구조 활용)

회원 목록 조회 : /members
회원 조회 : /member/{id}
회원 등록 : /members/{id}
회원 수정 : /members/{id}
회원 삭제 : /members/{id}

참고 : 계층 구조상 상위를 컬렉션으로 보고 복수 단어 사용 권장함.
(member -> members)

• 위와 같이 했을 때 문제 : 회원 조회 / 회원 등록 / 회원 수정 / 회원 삭제 구분을 어떻게 할지?....

리소스와 행위를 분리. (가장 중요한 것은 리소스를 식별하는 것)

URI는 리소스만 식별. (URI는 리소스를 판별할때 사용)

리소스와 해당 리소스를 대상으로 하는 행위를 분리.

리소스 : 회원

행위 : 조회 / 등록 / 삭제 / 변경

리소스는 명사, 행위는 동사(미네랄을 캐라)

• 그렇다면 행위(메서드)는 어떻게 구분?.. -> HTTP 메서드가 식별.

## HTTP 메서드 (GET, POST)

• GET : 리소스 조회
• POST : 요청 데이터 처리 (주로 등록에 사용)
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH  : 리소스 부분 변경
• DELETE : 리소스 삭제
• HEAD : GET 과 동이랗지만 메시지 부분을 제외, 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션 (메서드)을 설명 (주로 CORS에서 사용)
• CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

1. GET (리소스 조회)

서버에 전달하고 싶은 데이터는 query (쿼리 파라미터, 쿼리 스트링)를 통해 전달.

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

2. POST (요청 데이터 처리)

• 핵심 : 메시지 바디를 통해 서버로 요청 데이터 전달.
• 서버는 요청 데이터를 처리.
• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능 수행.
• 주 용도 : 주로 전달된 데이터로 신규 리소스 등록 / 프로세스 처리에 사용.
• 스팩 : POST 메스드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 쵸어 한다.

POST는 다음의 기능에 사용.
1. HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공.
- 예) HTML, FROM에 입력한 정보로 회원가입, 주문 등에 사용

2. 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시.
- 예) 게시판 글쓰기, 댓글 달기

3. 서버가아직 식별하지 않은 새 리소스 생성.
- 예) 신규 주문 생성

4. 기존 자원에 데이터 추가.
- 예) 한 문서 끝에 내용 추가하기 등

참고 : 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.
(정해진 것이 없다.)

• POST 정리

1. 새 리소스 생성(등록)
 서버가 아직 식별하지 않은 새 리소스 생성
 
2. 요청 데이터처리
- 단순히 데이터를 생성하거나, 변경하는 것을 넘어 프로세스를 처리해야 하는 경우
예) 주문에서 결제완료 > 배달시작 > 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
- POS의 결과로 새로운 리소스가 생성되지 않을 수도 있다.
예) POST/orders/{orderId}/start-delivery (컨트롤 URI)

3. 다른 메서드로처리하기 애매한 경우
- 애매하면 POST 사용
예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

3. PUT (리소스를 완전히 대체)

• 리소스가 있으면 '완전히' 대체, 리소스가 없으면 생성 (덮어쓰기)
• 주의 : 리소스를 '완전히' 대체한다. 
• 중요 : 클라이언트가 리소스를 식별. (클라이언트가 리소스 전체 위치를 알고 URI 지정 - POST와의 가장 큰 차이)

4. PATCH (리소스 부분 변경)

• 리소스를 부분적으로 변경할 때 사용. (PATCH 지원 안될 경우에는 POST 사용)

5. DELETE (리소스 제거)

• 리소스를 제거할 때 사용.

## HTTP 메서드의 속성

1. 안전 (Safe Methods)

• 호출해도 리소스를 변경하지 않는 것.
• 계속 호출해서 로그가 쌓여장애가 발생한다면? -> 안전은 해당 리소스만을 고려.
• 멱등 (Idempotent Methods)
• 몇 번을 호출해도 결과가 동일.

2. 멱등 메서드

GET : 여러번 조회해도 같은 결과 조회.

PUT : 결과를 대체. (같은 요청 여러번 해도 최종 결과는 동일)

DELETE : 결과를 삭제. (같은 요청 여러번 해도 삭제된 결과 동일)

POST : 멱등이 아님!!!!!!! 두 번 호출하면 같은결제가 중복해서 발생할 수 있다.

• 멱등 활용 : 자동 복구 메커니즘에 활용.
• 재 요청 중간에 다른 곳에서 리소스를변경해 버리면? -> 멱등은 외부 요인으로 중간에 리소스가 변경되는 것은 고려하지 않음.

3. 캐시가능 (Cacheable Methods)

• 응답 결과 리소스를 캐시해서 사용해도 되는지?
• GET / HEAD / POST / PATCH 에서 캐시 가능.
• 실제로는 GET / HEAD 정도만 캐시로 사용. (POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현 쉽지 않음)

# DML (Data Manipulation Language)

• SELECT (조회) / INSERT (입력) / UPDATE (수정) / DELETE (삭제)
• 데이터베이스에 저장된 데이터를 조회,  입력, 수정, 삭제하는 데 사용하는 질의어.
• 비절차적데이터 조작어.
• 사용자가 무슨(What) 데이터를 원하는지만을 명세.
• 데이터 부속어 (Data Sub Language) : C언어와 같은 호스트 프로그램 속에 삽입되어 사용되는 DML.

## DML 유형

1. SELECT

• 데이터 조회.
• 테이블을 구성하는 레코드 중 전체 또는 조건을 만족하는 레코드를 조회.

SELECT 문법)
SELECT [ALL | DISTINCT] 컬럼명 AS 별명
FROM 테이블명

=>
- SELECT 절에서 명시한 컬럼을 FROM 절의 테이블에서 조회.
- ALL, DISTINCT 키워드는 생략 가능
  (생략 시 기본적으로 ALL로 인식)
- ALL : 중복되는 데이터도 모두 조회(Default)
- DISTINCT : 중복된 데이터가 있는 경우 중복 제거하여 1건만 조회.
- AS : AS 키워드를 사용해서 컬럼의 별명(ALIAS) 변경 가능. 
  (AS 생략 가능)
- SELECT 절에서 WILDCARD(*) 및 ESCAPE 사용 가능.

2. INSERT

• 데이터 입력.
• 테이블에 새로운 레코드를 입력할 때 사용.

INSERT 문법 1)
INSERT INTO 테이블명(컬럼명) VALUES(입력값);

=>
- 데이터를 입력하고자 하는 테이블의 컬럼을 정의하여 데이터 입력.
- 컬럼과 입력값은 1:1 매핑, 정의하지 않은 컬럼은 디폴트로 NULL 입력.



INSERT 문법 2)
INSERT INTO 테이블명 VALUES (입력값);

=>
- 컬럼 생략하는 경우 모든 컬럼을 대상으로 데이터 입력.
- 입력값은 테이블의 컬럼 수와 같아야 함.

3. UPDATE

• 데이터 수정.
• 테이블에 있는 레코드 중 특정 레코드의 내용을 변경할 때 사용.

UPDATE 문법)
UPDATE 테이블명
  SET 컬럼명 = 입력값
WHERE 조건;

=>
- UPDATE 문의 테이블에서 SET 절의 컬럼을 입력값으로 수정.
- WHERE 절에서 데이터 수정 조건을 정의.

4. DELETE

• 데이터 삭제.
• 테이블에 있는 레코드 중 특정 레코드를 삭제할 때 사용.

DELETE 문법)
DELETE [FROM] 테이블명
WHERE 조건;

=>
- DELETE 문의 테이블에서 WHERE 절의 조건에 맞는 데이터 삭제.
- FROM 키워드 생략 가능.

# TCL (Transaction Control Language)

• COMMIT / ROLLBACK / SAVEPOINT
• 트랜잭션 제어 명령어.
• 트랜잭션 : 업무 처리를 위한 데이터베이스의 논리적인 작업의 단위, 하나의 트랜잭션은 한 개 이상의 연산으로 이루어질 수 있고 해당 연산들은 완전히 처리 되거나 아예 한 개도 처리되지 않아야 한다. (All or Nothing)

1. COMMIT

• 올바르게 수행된 트랜잭션의 결과를 데이터베이스에 반영.

COMMIT 문법)
INSERT INTO EMP
VALUES (102, 'AAA', 15, 100);
COMMIT;

=>
- INSERT 문을 이용하여 EMP 테이블에 데이터 입력.
- COMMIT 을 통해트랜잭션을 완료하고 데이터를 데이터베이스에 반영.

• SQL Server : 기본적으로 AUTO COMMIT 모드, DML 구문이 성공이면 자동으로 COMMIT수행되고 오류가 발생하면 자동으로 ROLLBACK 이 수행된다. (AUTO COMMIT OFF인 경우 DDL 수행되어도 묵시적으로 COMMIT수행되지 않음)
• ORACLE : 기본적으로 AUTO COMMIT OFF로 설정된 상태에서 DDL 수행 시 묵시적으로 COMMIT 수행

2. ROLLBACK

• 문제 발생 시 하나의 트랜잭션을 취소.

ROLLBACK 문법)
UPDATE EMP
  SET EMP_NAME = 'AAAA'
WHERE EMP_NAME = 'B'
ROLLBACK;

=>
- UPDATE 문장으로 EMP 테이블에서 EMP_NAME이 'B' 이면 'AAAA' 로 변경.
- ROLLBACK 명령으로 트랜잭션을 취소하여 UPDATE 문장이 데이터베이스에 반영되지 않도록 함.

• SQL Server : CREATE TABLE도 트랜잭션의 범주에 포함되어ROLLBACK 가능.

3. SAVEPOINT

• 하나의 트랜잭션을 작게 분할하여 저장하는 기능을 수행.

SAVEPOINT 문법)
SAVEPOINT SP1;
INSERT INTO EMP VALUES(100, 'AAA', 30);
SAVEPOINT SP2;
UPDATE EMP
  SET EMP_NAME = 'AAAA'
WHERE EMP_NAME = 'B'
ROLLBACK TO SP2;

=>
- SAVEPOINT 저장점명; 으로 SP1 저장점 지정.
- INSERT 문으로 EMP 테이블에 데이터 입력.
- SAVEPOINT 저장점명; 으로 SP2 저장점 지정.
- UPDATE 문으로 EMP 테이블 데이터 업데이트.
- ROLLBACK TO 저장점명; 으로 트랜잭션을 취소.
  (SP2로 롤백하여 UPDATE 문의 실행은 데이터베이스에 반영되지 않도록 함)

# 모든 개발자를 위한 HTTP 웹 기본 지식 학습

# HTTP 메서드

## PUT

• 리소스를 대체한다.

리소스가 있으면 대체

리소스가 없으면 생성

=>
쉽게 얘기하면 덮어버림

• 중요! 클라이언트가 리소스를 식별한다.

클라이언트가 리소스 위치를 알고 URI를 지정한다.
(POST와 다른점)

### PUT1 - 리소스가 있는 경우 1

• 클라이언트가 /members 100번에 리소스를 넣을 것이라고 지정하고 데이터를 보낸다.

PUT/members/100 HTTP/1.1
Content-Type: application/json

{
	"username":"old",
    "age":50
}

• 서버에서 확인했을 때 /members 100번에 이미 데이터가 존재한다면,

/members/100
{
	"username":"young",
    "age":20
}

### PUT - 리소스가 있는 경우 2

• 서버에 있는 리소스가 클라이언트로부터 받은 리소스로 대체가 된다.

/members/100
{
	"username":"old",
    "age":50
}

### PUT - 주의!! 리소스를 완전히 대체한다 1

• /members 100번에 age만 업데이트 하고 싶은 경우..

PUT/members/100 HTTP/1.1
Content-Type: application/json

{
    "age":50
}

• 서버에 있는 리소스가..

/members/100
{
	"username":"young",
    "age":20
}

### PUT - 주의!! 리소스를 완전히 대체한다 2

• 클라이언트가 보낸 리소스로 대체되면서 기존 username 필드가 삭제된다.
• 이와 같은 문제 해결 위해서는 PATCH 사용.

/members/100
{
    "age":20
}

## PATCH

• 리소스를 부분 변경한다.

### PATCH - 리소스 부분 변경 1

• PATCH로 변경하고자 하는 부분만 전송(age만 변경 희망, username 필드 없음)

PATCH/members/100 HTTP/1.1
Content-Type: application/json

{
    "age":50
}

• 서버에 기존 리소스가..

/members/100
{
	"username":"young",
    "age":20
}

### PATCH - 리소스 부분 변경 2

• 변경 희망하는 age만 부분 변경된다.

/members/100
{
	"username":"young",
    "age":50
}

## DELETE

• 리소스 제거

### DELETE - 리소스 제거 1

• DELETE로 members 100번에 대한 제거 요청

DELETE /members/100 HTTP/1.1
Host: localhost:8080

• 서버에 있던 기존 리소스가..

/members/100
{
	"username":"young",
    "age":20
}

### DELETE - 리소스 제거 2

• 기존에 서버에 있던 /members 100번 리소스가 제거된다.

### PUT / PATH / DELETE 정리

• PUT : 완전히 대체한다.
• PATCH: 리소스를 부분 변경한다. (간혹 PATCH를 지원하지 않는 경우엔 POST로 진행)
• DELETE : 리소스를 삭제한다.

# HTTP 메서드의 속성

• 안전 (Safe Methods)
• 멱등 (Idenmpotent Methods)
• 캐시가능 (Cacheable Methods)

## 안전 (Safe)

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

Q : 그래도 계속 호출해서, 로그 같은게 쌓여 장애가 발생한다면?

A : 안전은 해당 리소스만 고려하므로, 그런 부분은 고려하지 않는다.

## 멱등 (Idenmpotent)

• f(f(x)) = f(x)
• 한 번 호출하든, 두 번 호출하든 100번 호출하든 결과는 똑같다.
• 멱등 메서드

GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.

PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.

DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

* POST : 멱등이 아니다!! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

### 멱등의 활용

• 자동 복구 메커니즘
• 서버가 TIMEOUT 등 으로 정상 응답을 못 주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가?의 판단 근거가 된다.

### 멱등 Q : 재요청 중간 다른 곳에서 리소스를 변경해버리면?

사용자 1 : GET 으로 조회 > username : A / age : 20

사용자 2 : PUT 으로 변경 > username : A / age : 30

사용자 1 : GET 으로 조회 > username : A / age : 30

사용자 2의 영향으로 바뀐 데이터가 조회된다.

A : 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다!

## 캐시가능 (Cacheable)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시 가능
• 실제로는 GET, HEAD 정도만 캐시로 사용한다.
• POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않다.
• 즉, 실무에서는 거의 GET 만 캐시로 사용된다.

출처 : 인프런 모든 개발자를 위한 HTTP 웹 기본 지식

* CRUD (Create / Read / Update / Delete)

- 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create (생성) / Read (읽기) / Update (갱신) / Delete (삭제) 를 묶어서 일컫는 말.