참고
데이터 전달 방식
NOTE
데이터 전달 방식은 크게 2가지 경우로 나뉜다!
•
쿼리 파라미터를 통한 데이터 전송
◦
GET
◦
주로 정렬 필터(검색어)
•
메시지 바디를 통한 데이터 전송
◦
POST, PUT, PATCH
◦
회원 가입, 상품 주문, 리소스 등록, 리소스 변경
•
4가지 상황
1.
정적 데이터 조회 ( 이미지, 정적 텍스트 문서 )
2.
동적 데이터 조회 ( 검색, 게시판 목록에서 정렬 필터 검색)
3.
HTML Form을 통한 데이터 전송 ( 회원가입, 상품 주문, 데이터 변경 )
4.
HTTP API를 통한 데이터 전송 ( 회원가입, 상품 주문, 데이터 변경, Ajax )
정적 데이터 조회
NOTE
GET을 사용하면서, 쿼리 파라미터 없이 조회 가능
•
이미지, 정적 텍스트 문서
동적 데이터 조회
NOTE
GET을 사용한다. 쿼리 파라미터를 사용해서 조회 가능
•
검색, 게시판 목록에서 정렬 필터(검색어)
HTML Form을 통한 데이터 전송
NOTE
POST 전송 - 저장
서버가 POST 메시지를 받고 데이터를 저장한다!
application/w-xxx-urlencoded ⇒ 일반적인 form을 전송할 떄 쓰는 타입
multipart/form-data ⇒ 파일(binary data)을 전송할 떄 쓰는 인코딩 타입
•
post method로 된 Form 태그의 submit 버튼을 누르면 , 웹 브라우저가 HTML Form의 데이터를 읽어서 HTTP 요청 메시지를 생성해준다.
GET 전송 - 저장
GET은 조회에서만 사용해야한다. 변경에 사용하면 안됨!
•
get method로 된 Form 태그의 submit 버튼을 누르면, 웹 브라우저가 HTML Form의
데이터를 읽어서 HTTP 요청 메시지를 생성해준다.
GET 전송 - 조회
GET 메시지를 받으면, 데이터를 조회한 결과를 응답한다.
•
get method로 된 Form 태그의 submit 버튼을 누르면, 웹 브라우저가 HTML Form의
데이터를 읽어서 HTTP 요청 메시지를 생성해준다.
HTTP API를 통한 데이터 전송
NOTE
GET → 쿼리 파라미터로 전달
POST, PUT, PATCH → 메시지 바디를 통해 전달
•
Content-Type : application/json을 주로 사용한다.
HTTP API 설계
NOTE
POST 기반으로 등록, PUT 기반으로 등록하는 2가지 경우의 특지을 아는것이 중요하다
1.
HTTP API - 컬렉션
•
POST 기반, 회원 관리 API제공
2.
HTTP API - 스토어
•
PUT 기반, 정적 컨텐츠 관리, 원격 파일 관리
3.
HTTP FORM 사용
•
GET, POST만 지원, 웹 페이지 회원 관리
회원관리 시스템(컬렉션 - POST)
NOTE
컬렉션 ⇒ 서버가 관리하는 리소스 디렉토리, 서버가 URI를 생성하고 관리한다!
POST 기반 등록
컬렉션 =/ members
•
회원 수정은 PATCH, PUT, POST 중 무엇으로 구현하는 것이 좋을까?
◦
PATCH
▪
리소스 부분 변경
◦
PUT
▪
기존 리소스를 덮어써도 문제가 없는 경우
◦
POST
▪
거의 대부분에서 사용됨
신규 자원 등록 특징
members의 몇번쨰 ID가 생성되는지 모른다.
파일 관리 시스템(스토어 - PUT)
NOTE
스토어 ⇒ 클라이언트가 관리하는 리소스 저장소, 클라이언트가 URI를 관리한다!
PUT 기반 등록
스토어 = /files
•
파일 등록같은 경우는 해당 파일이 있으면 기존 것을 덮어써야하기 때문에, Put을 사용
신규 자원 등록 특징
직접 리소스 URI를 지정해서 요청한다!
HTML FORM 사용
NOTE
HTML FORM은 GET, POST만 지원하므로 제약이 존재한다!
HTML FORM API 설계
HTML FORM은 GET, POST만 지원하므로 컨트롤 URI를 써서 해결한다
ex) /members/{id}/delete POST
•
컨트롤 URI
◦
GET, POST만 지원하는 제약을 해결하기 위해 동사로 된 리소스 경로 사용
▪
EX) POST의 /new, /edit, /delete가 컨트롤 URI
◦
HTTP 메서드로 해결하기 애매한 경우 사용한다
◦
HTML FORM이 아니더라도 사용이 가능함
질문 정리
Q. HTTP Form과 HTTP API의 차이점은?
•
먼저 응답 결과(response)로 무엇을 전달받느냐에 따라 크게 2가지로 나눌 수 있다.
1) HTML 을 전달받는 것
2) 데이터를 전달받는 것
•
HTTP API는 응답결과로 HTML이 아닌 데이터를 전달받는 것을 말한다
Q. GET으로 게시판 글 조회를 할 때 글 조회수가 올라가도록 구현하는 것이 멱등성을 위반하게 되는 것 인가요? 그러면 GET이 아닌 POST로 구현해야하나요?
•
모호한 부분이지만 GET을 사용하는것이 맞다
•
조회수가 올라가는 부분이 게시글 자체의 리소스를 변경하는 것은 아니기 때문이다!
•
애플리케이션 내부의 로그를 남기는 부분에서 GET을 사용하는건 모두 허용된다.
Q. HTML Form 태그를 사용해서 데이터 수정을 해야할 떄는 어떻게 해야 하나요?
Q. 특정 데이터를 삭제해야할 때 DB에서 물리적으로 지우지 않고 useYN같은 삭제 여부 필드를 두기도 합니다. 비즈니스 상으로는 삭제이지만 실제 DB 데이터를 지우는 것이 아니라 useYN 필드 값을 Y에서 N으로 수정하는 것이니 DELETE 메서드가 아니라 PATCH 메서드를 쓰는 것이 더 적합하지 않나요?
•
실무에서도 DELETE는 매우 신중하게 사용해야한다
•
HTTP로 제공하는 인터페이스 내부 구현과는 분리되도록 작업해야 한다
•
그래서 내부에서 실제 리소스를 삭제하든, useYN을 사용하든 구현할 때 적절한 방안을
선택하면 된다
•
따라서 외부에도 DELETE 메서드로 제공하고, 내부에서는 실제 DB를 사용하지 않고
useYN의 값을 변경하는 것 처럼 사용해도 된다.
HTTP 상태코드
NOTE
상태코드 ⇒ 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
대표적으로 2xx, 4xx, 5xx 에러를 자주본다.
•
1xx (Informational)
◦
요청이 수신되어 처리중
•
2xx (Successful)
◦
요청 정상 처리
•
3xx (Redirection)
◦
요청을 완료하려면 추가 행동이 필요
•
4xx(Client Error)
◦
클라이언트 오류, 잘못된 문법으로 서버가 요청 수행못함
•
5xx(Server Error)
◦
서버 오류, 서버가 요청을 정상적으로 처리하지 못함
2xx (Successful)
NOTE
200 - OK(요청 성공)
200 → 데이터가 성공적으로 클라이언트에게 응답된다!
201 - Created(요청 성공 후 새로운 리소스 생성)
201 → POST와 같은 명령어로 새로운 리소스가 생성됨!
기타
•
202 - Accepted(요청이 접수되었으나 처리가 완료되지 않음)
◦
배치 처리 같은 곳에서 사용( 잘 안쓰임 )
◦
ex) 요청 접수 후 1시간 뒤 배치 프로세스가 요청을 처리함
•
204 - No Content(서버가 요청을 성공적으로 수행했으나, 보낼 데이터가 없음)
◦
결과 내용이 없어도 204메시지(2xx)로 성공 인식 가능
3xx 리다이렉션
NOTE
요청을 완료하기 위해선 웹 브라우저의 추가적인 조치가 필요하다!
리다이렉션의 종류
301 응답의 Location으로 이동한뒤 /new-event로 요청보내서 응답을 받는다.
•
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동이동한다.(리다이렉트)
영구 리다이렉션(301, 308)
NOTE
리소스의 URI가 영구적으로 이동
301 Moved Permanetly
리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.
308 Permannet Redirect
리다이렉트 요청 메서드가 본문 메서드와 동일
자동 리다이렉트되어 입력한 정보 그대로 등록된다.
•
실무에서는 308을 거의 사용하지 않는다!
◦
만약 /event 에서 /new-event로 URI가 바뀌면 내부적으로 전달해야하는 데이터
자체가 바뀌기 떄문에, POST로 요청을 받아도 GET으로 바뀌는게 맞음!
일시적 리다이렉션(302, 307, 303)
NOTE
리소스의 URI가 일시적으로 변경된다!
•
302 Found
◦
리다이렉트 요청 메서드가 GET으로 변한다.
◦
본문이 제거 될 수도있다(MAY)
•
307 Temporary Redirect
◦
리다이렉트 요청 메서드와 본문 유지
◦
요청 메서드 변경 불가 = MUST NOT
•
303 See Other
◦
리다이렉트시 요청 메서드가 GET으로 변경
일시적 리다이렉션(PRG: Post/Redirect/Get)
NOTE
POST로 주문 후에 웹 브라우저를 새로고침하면 중복 주문이 될 수 있다
•
POST로 주문 후에 새로 고침으로 인한 중복주문 방지
•
POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
•
중복 주문 대신에 결과 화면만 GET으로 다시 요청
•
(참고) : 새로고침은 마지막에 요청한 reuqest를 재요청 하도록 정의하고 구현됨
PRG(POST/REDIRECT/GET) 사용 전
새로고침하면 무한결제가 이루어질 수 있다..
PRG(POST/REDIRECT/GET) 사용 후
결제이후 바로 302 REDIRECT를 이용해서, URI를 변경해버림
새로고침해도 결제안함
기타 리다이렉션(300, 304)
NOTE
•
300 Multiple Choices
◦
사용 x
•
304 Not Modified
◦
캐시 목적으로 사용
◦
클라이언트에게 리소스가 수정되지 않았음을 알려줌 → 로컬PC에 저장된 캐시 재사용
4xx 클라이언트 에러
NOTE
400 Bad Request
•
클라이언트가 잘못된 요청을해서 서버가 요청을 처리할 수 없음
◦
요청구문, 메시지 등 오류
◦
클라이언트는 내용을 재검토 후 보내야한다
◦
ex) 요청 파라미터가 틀렸거나, API 스펙에 맞지않을 때
401 Unauthorized
인증 ⇒ 클럽 출입증
인가 ⇒ 클럽 내부 권한
•
클라이언트가 해당 리소스에 대한 인증이 필요함
◦
인증이 되지 않아 생긴오류
◦
401 오류 발생시, 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
403 Forbidden
•
서버가 요청을 이해했지만 승인을 거부함
◦
인증은 됐지만 접근 권한이 불충분함
◦
어드민 등급이 아닌 사용자가 로그인은 했지만 어드민 등급의 리소스에 접근하는 경우
404 Not Found
•
요청 리소스가 서버에 없는 경우
•
클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶은 경우
5xx 서버 에러
NOTE
500 Internal Server Error
•
서버 문제로 오류 발생, 애매하면 500오류
503 Service Unavailable
•
서비스가 일시적인 과부하/예정된 작업으로 잠시 요청을 처리할 수 없음
•
Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수 있음
질문 정리
Q. 서버 측에서 동일 주문 중복 방지를 하기 위해 어떻게 구현해야하나요?
•
보통 주문 화면에 들어가는 시점에 서버에서 임시 주문 번호를 발급해두는데, 주문 번호는 다음과 같이 만들 수 있다.
1.
DB가 제공하는 중복없이 순서대로 값이 증가하는 시퀀스 값을 사용
2.
UUID 사용
Q. 20세 이상에게만 제공하는 서비스에 15살이 들어온 경우, 5xx가 아닌 어떤 에러를 출력해야하나요?
1.
클라이언트와 서버가 서로 약속한 HTTP API 스펙을 만족하면 -> 200,
만족하지 않으면 -> 400
2.
비즈니스 로직이 정상 수행되지만 다양한 결과가 존재하는 경우(승인, 거절 등) -> 200 + 비즈니스 코드 반환(봉투 패턴)
3.
비즈니스 로직을 수행하다가 내부에서 시스템 예외나 NullPointerException 등 비즈니스와 관계없는 시스템 예외 발생 -> 500
•
(참고) 다양한 비즈니스 응답이 있는 복잡한 비즈니스 로직이 있는 HTTP API는 봉투 패턴 고려, 비즈니스 로직이 거의 없는 단순한 조회는 봉투 패턴 고려X
Q. 구글에서 검색해서 나온 페이지를 클릭해 들어가면 404 Not Found가 뜨는 경우는 리소스가 있는데 리소스를 숨기는 건가요?
•
이 경우는 대부분 검색 엔진이 크롤링 하는 단계에서는 리소스가 있었는데, 이후 리소스가 사라져 404 Not Found가 뜨는 것이다.