HTTP 웹 기본지식 - 2

HTTP 메서드

API URI 고민

 

URI는 리소스만 식별해야 한다.

 

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

리소스는 명사(URI), 행위는 동사다(Method).

 

 

HTTP 메서드 종류

1. GET: 리소스 조회

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

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

4. PATCH: 리소스 부분 변경

5. DELETE: 리소스 삭제

6. 기타메서드: HEAD, OPTIONS, CONNECT, TRACE 등등

 

1. GET

리소스 조회

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

메시지 바디를 사용할 수는 있지만 범용적이지 않아 사용하지 않는 것이 좋다.

 

 

2. POST

요청 데이터 처리

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

서버는 요청 데이터를 처리(메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능)

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

 

POST 메서드는 대상 리소스가 리소스의 교유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청한다.

1. HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공

2. 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시

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

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

 

정리: 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야함

결론적으로 아래와 같은 요청도 POST로 사용한다.

1. 요청 데이터 처리 - 프로세스를 처리해야 하는 경우

2. 다른 메서드로 처리하기 애매한 경우 - JSON으로 데이터를 넘겨야 하는데 GET을 쓰기 어려운 경우

 

 

3. PUT

리소스를 대체할 때 쓴다. 쉽게 말해 덮어버린다.

- 리소스가 있으면 대체

리소스가 있는 상황

 

- 같은 방식으로 리소스가 없으면 생성한다.

 

중요! PUT은 클라이언트가 리소스를 식별한다. - POST와의 차이점

 

4. PATCH: 리소스 부분 변경

 

 

5. DELETE: 리소스 제거

 

---

HTTP 메서드의 속성

1. 안전(Safe Methods)

2. 멱등(Idempotent Methods)

3. 캐시가능(Cacheable Methods)

 

1. 안전

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

 

2. 멱등

한 번 호출하든 두 번 호출하든 몇 번을 호출해도 결과가 똑같다.

- GET: 같은 결과가 조회된다.

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

- DELETE: 결과를 삭제한다. 같은 요청에도 삭제된 결과는 같다.

- POST: 멱등이 아니다. 두 번 호출하면 같은 결제가 중복되어 발생할 수 있다.

 

활용:

- 자동 복구 메커니즘

- 서버가 TIMEOUT 등으로 정상 응답을 못주었을때 같은 요청을 해도 되는가의 판단 근거

 

멱등은 외부 요인으로 중간에 리소스 변경까지는 고려하지 않는다.

 

3. 캐시가능

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

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

 

---

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

1. 정적 데이터 조회

 - 이미지, 정적 텍스트 문서

2. 동적 데이터 조회

 - 주로 검색, 게시판 목록에서 정렬 필터

3. HTML Form을 통한 데이터 전송

 - 회원가입, 상품주문, 데이터 변경

4. HTTP API를 통한 데이터 전송

 - 회원가입, 상품주문, 데이터변경, 서버 to 서버, 앱 클라이언트, 웹 클라이언트(Ajax)

 

 

1. 정적 데이터 조회

쿼리 파라미터 미사용

- 이미지, 정적 텍스트 문서

- 조회는 GET 사용

- 정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회 가능

 

2. 동적 데이터 조회

쿼리 파라미터 사용

- 주로 검색, 게시판 목록에서 정렬 필터

- 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용

- 조회는 GET 사용

- GET은 쿼리 파라미터를 사용해서 데이터를 전달

 

3. HTML Form 데이터 전송

save에 GET을 사용하면 안된다.

multipart/form-data. default는 x-www-form-urlencoded지만 multipart/form-data는 바이트 파일까지 전송해야 한다. 따라서 전송하면 알아서 폼을 나눠서 전송해준다.

HTML Form 데이터 전송

- HTML Form submit시 POST 전송

-Content-Type: application/x-www-form-urlencoded 사용, form의 내용을 메시지 바디를 통해서 전송, 전송 데이터를 url encoding 처리

- HTML Form은 GET 전송도 가능

- Content-Type: multipart/form-data는 파일 업로드 같은 바이너리 데이터 전송시 사용, 다른 종류의 파일과 폼의 내용 전송 가능

HTML Form은 GET, POST만 지원

 

4. HTTP API 데이터 전송

- 서버 to 서버

- 앱 클라이언트

- 웹 클라이언트

- POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송

- GET: 조회, 쿼리 파라미터로 데이터 전달

- Content-Type:aplication/json을 주로 사용

 

 

HTTP API설계 예시

1. 회원 관리 시스템

API 설계 = POST 기반 등록

 

• 회원 목록 /members -> GET

• 회원 등록 /members -> POST

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

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

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

 

클라이언트는 등록될 리소스의 URI를 모른다.

서버가 새로 등록된 리소스 URI를 생성해준다.

 

2. 파일 관리 시스텡

 

API 설계 = PUT 기반 등록

 

• 파일 목록 /files -> GET

• 파일 조회 /files/{filename} -> GET

• 파일 등록 /files/{filename} -> PUT

• 파일 삭제 /files/{filename} -> DELETE

• 파일 대량 등록 /files -> POST

 

클라이언트가 리소스 URI를 알고 있어야 한다.

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

 

3. HTML Form 사용

HTML FORM은 GET, POST만 지원하기 때문에 제약이 있다.

AJAX같은 기술을 사용해서 해결 가능

 

• 회원 목록 /members -> GET

• 회원 등록 폼 /members/new -> GET

• 회원 등록 /members/new, /members -> POST

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

• 회원 수정 폼 /members/{id}/edit -> GET

• 회원 수정 /members/{id}/edit, /members/{id} -> POST

• 회원 삭제 /members/{id}/delete -> POST

 

 

 

참고하면 좋은 URI 설계 개념

---

HTTP 상태 코드

• 1xx (Informational): 요청이 수신되어 처리중

• 2xx (Successful): 요청 정상 처리

• 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요

• 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음

• 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

 

1. 2xx(Successful)

200 OK

201 Created: 요청 성공해서 새로운 리소스가 생성됨

202 Accepted: 요청이 접수되었으나 처리가 완료되지 않았음(배치 처리에서 사용)

204 No Content: 서버가 요청을 성공적으로 수행했지만 응답 페이로드 본분에 보낼 데이터가 없음(문서편집기)

 

2. 3xx(Redirection)

300 Multiple Choices

301 Moved permanently

302 Found

303 See Other

304 Not Modified

307 Temporary Redirect

308 Permanent Redirect

 

리다이렉션의 이해: 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동 이동

1. 영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동

2. 일시 리다이렉션: 일시적인 변경(주문 완료 후 주문 내역 화면으로 이동), ㅖㄲㅎ

3. 특수 리다이렉션: 결과 대신 캐시를 사용

 

1. 영구 리다이렉션

301 Moved permanently

리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음

308 Permanent Redirect

301과 기능은 같지만 리다이렉트시 요청 메서드와 본문 유지

 

2. 일시적인 리다이렉션

302, 307, 303

리소스의 URI가 일시적으로 변경

검색 엔진 등에서 URL을 변경하면 안됨

302 Found: 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(May)

308 Temporary Redirect: 302와 기능은 같다. 리다이렉트시 요청 메서드와 본문 유지(Must)

303 See Other: 302와 기능은 같지만 리다이렉트 요청 메서드가 GET으로 변경

 

PRG: Post/Redirect/Get

일시적인 리다이렉션

POST로 주문 후에 웹 브라우저를 새로고침하면 중복 주문이 될 수 있다. 따라서 PRG를 사용해야 한다.

 

POST로 주문 후에 주문 결과 화면을 GET메서드로 리다이렉트 해주면 새로고침해도 결과 하면을 GET으로 조회한다.

 

결론: 307, 303이 권장되지만 이미 많은 라이브러리들이 302를 사용하고 있기 때문에 그냥 302를 사용해도 된다.

 

3. 기타 리다이렉션

300 Multiple Choices: 안쓴다

304 Not Modified: 캐시를 목적으로 사용

-클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다.

-304 응답은 메시지 바디를 포함하면 안된다.

-조건부 GET, HEAD 요청시 사용

 

4xx(Client Error)

클라이언트의 요청이 잘못된 문법등으로 서버가 요청을 수행할 수 없다. 오류의 원인이 클라이언트에 있다.

 

400 Bad Request: 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음

401 Unauthorized: 클라이언트가 해당 리소스에 대한 인증이 필요함

403 Forbidden: 서버가 요청을 이해했지만 승인을 거부함

404 Not Found: 요청 리소스를 찾을 수 없음

 

 

5xx(Server Error)

서버 문제로 발생, 서버에 문제가 있기 땜누에 재시도 하면 성공할 수 있음

503 Service Unavailable: 일시적 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음