서버에서 클라이언트의 메세지를 받고 응답을 주는 것에 대해서 클라이언트의 처리를 구현하면 됨
(b) 서버 입장
RESTFUL하게 구현하여 적절한 응답을 띄우도록 해야 함, 500번대는 반드시 피하도록
2. 1xx (Informational)
2-1) 정의
요청이 수신되어 처리중이라는 것을 알려줌
- 거의 사용하지 않으므로 생략
3. 2xx (Success)
2-1) 정의
요청이 수신되어 성공적으로 처리하였음
200 OK : 클라이언트 요청 수행 성공 GET 같은 경우
201 Created : POST로 create할 때 POST 메서드 사용시 전체 url이 아닌 부분 경로까지 지정해주면 create 자체는 서버에서 담당
※ POST는 universial 하게 쓰일 수 있고 (1) 새 resource를 생성을 하지 않더라도 특정 기능을 서버가 수행해야 할 때 (2) Body에 데이터를 넣어서 전달해야할 때 등의 상황에서 쓰임
※ Header의 location에 정보 위치를 표기해줌, 201을 통해 잘 생성되었다는 것을 확인할 수 있음
202 Accepted : 요청이 접수 되었으나 처리가 완료가 되지 않음 - ex) 요청은 받았으나 job은 일정시간 이후에 처리 가능할 때 - 잘 사용하지는 않음
204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음 → 클라이언트가 요청을 하면 서버가 응답을 하고 보통 그 body에 데이터가 포함됨 응답 데이터에 포함시킬 데이터가 존재하지 않는 작업의 경우 204 > ex) 웹 문서 편집기에서 save 버튼 - 본문 내용같은 것을 body로 server에게 client가 응답을 받아도 할 수 있는 것이 없는 경우임 - save 버튼의 결과로 아무 내용이 없어도 됨 - save 버튼을 눌러도 같은 화면을 유지해야 한다 - 결과 내용이 없어도 204만으로 성공을 인식할 수 있다
※ 페이로드란?
페이로드(payload)는 전송되는 데이터를 의미합니다. 데이터를 전송할 때, 헤더와 메타데이터, 에러 체크 비트 등과 같은 다양한 요소들을 함께 보내어, 데이터 전송의 효율과 안정성을 높히게 됩니다. 이 때, 보내고자 하는 데이터 자체를 의미하는 것이 바로 페이로드입니다. 우리가 택배 배송을 보내고 받을 때, 택배 물건이 페이로드이고, 송장이나 박스, 뾱뾱이와 같은 완충재 등등은 부가적인 것이기 때문에 페이로드가 아닙니다.
추가적으로 위키피디아에 아주 이해하기 좋은 예시가 아래와 같이 나와있어서 첨부합니다.
페이로드(payload)라는 단어는 운송업에서 비롯하였는데, 지급(pay)해야 하는 적화물(load)을 의미합니다. 예를 들어, 유조선 트럭이 20톤의 기름을 운반한다면 트럭의 총 무게는 차체, 운전자 등의 무게 때문에 그것보다 더 될 것이다. 이 모든 무게를 운송하는데 비용이 들지만, 고객은 오직 기름의 무게만을 지급(pay)하게 된다. 그래서 ‘pay-load’란 말이 나온 것이다
json으로 보는 실제 데이터에서의 payload는 아래의 json에서 “data”입니다. 그 이외의 데이터들은 전부 통신을 하는데 있어 용이하게 해주는 부차적인 정보들입니다.
{
"status" :
"from": "localhost",
"to": "http://melonicedlatte.com/chatroom/1",
"method": "GET",
"data":{ "message" : "There is a cutty dog!" }
}
Client가 요청을 서버에 보냈을 때 Server가 요청을 완료하려면 추가 조치가 필요하다는 것을 알려주는 응답
※ User agent 란?
유저 웹브라우저 프로그램과 같은 Client 프로그램을 의미
> 모든 응답 번호
300은 잘 안쓰임
301 ~ 308 까지가 주요한 응답
4-2) 리다이렉션의 이해
(a) 정의
웹브라우저는(User agent)는 3xx 응답의 결과에 location 헤더에 값이 있으면, 해당 Location 위치로 자동으로 이동 (리다이렉트의 의미)
(b) 자동 리다이렉트의 흐름
상황 : /event 의 리소스 위치에 redirect page가 경로일 때, 옛날에 이벤트 페이지를 배포한 상태
→ 나중에 이 이벤트 페이지가 사용되지 않는 시점에서 새로운 event-page가 있을 때 옛날 사용자들 중에 이 옛날 event-page를 북마크해두거나 한 경우에 redirection을 해주어야 함
4-3) 리다이렉션의 종류
영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동 - /members →/users - /event →/new-event
일시 리다이렉션 : 일시적인 변경 - 주문 완료 후 주문 내역 화면으로 이동 - PRG : Post/Redirect/Get
특수 리다이렉션 : 캐시를 다시 조회를 해도 되는지에 대한 검증을 하는 redirection
4-4) 영구 리다이렉션
301, 308
(a) 특징
리소스의 URL/URI가 영구적으로 이동
원래의 URL/URI를 사용하면 안됨, 검색 엔진에서도 변경을 인지
> 301 Moved Permanently - 리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음( MAY ) 거의 모든 user-agent가 위의 방식으로 동작하도록 되어있음 [ POST로 요청해도 메서드가 변경, BODY 제거될 수 있음 ]
※ 301 과정
1) POST 메서드 사용 인지 POST는 신규 데이터 등록 OR 서버에 요청 처리 의미인데, body에 데이터가 쿼리스트링으로 담겨져왔으므로 신규 데이터 생성으로 인지(ex 사용자 정보 등록) 2) 들어온 URI/URL을 더이상 사용하지 않으므로 서버 응답이 301로 처리 헤더의 Location의 value로 이동 거의 모든 user-agent에서 위의 방식으로 동작 3) 브라우저의 자동 redirect 4) GET으로 새 페이지 요청 5) 200 ok와 함께 새 페이지 데이터 서버가 보내줌 → 다시 처음부터 데이터 등록을 위한 정보를 클라이언트에서 입력하여 주어야 하는 단점
> 308 Permanent Redirect - 301과 기능을 동일 - 리다이렉트 요청메서드와 본문을 유지 [ 원본 요청 메서드를 유지, BODY 내용 유지 ]
※ 308 과정
> POST 메서드와 본문 BODY내용을 유지하는게 301과 다른점
★ 스펙기준으로 설명을 이렇게 될 수 있다는 의미이고 실제는 redirect를 할 경우, client가 보내주어야 하는 데이터가 모두 바뀌는게 일반적이라서 301 redirect로 하고 다시 해당 page에서 POST데이터를 보내도록 하는 것이 맞음 → 301을 쓰는게 실무에서는 더 맞음
4-5) 일시적 redirection
302, 307, 303 영구 redirection은 실제로 영구적인 경우이고 small case이지만 일시적 redirection을 훨신 일반적으로 사용하고, 그 case가 많음
(a) 특징
리소스의 URI가 일시적으로 변경 → 따라서 검색엔진 등에서 URL을 변경하면 안됨 : 일시적으로 다른 page들리는 redirection이기 때문
> 302 Found - 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음( MAY ) - 보통 현업에서 / 실무에서 이 방식을 써도 무방 - 301과 동일한 결과
> 307 Temporary Redirection - 302와 기능은 동일 - 리다이렉트시 요청 메서드와 본문 유지(MUST NOT → 유지한다)
> 303 See Other - 302와 기능을 동일 - 리다이렉트시 요청메서드 GET 으로 변경( 반드시 명확하게 변경 됨 )
4-6) 기타 리다이렉션
300, 304
(a) 특징
300 Multiple Choices : 안씀
304 Not Modified - 캐시를 목적으로 사용 - 클라이언트에게 리소스가 수정되지 않았음을 알려주고, 클라이언트는 로컬 PC에 저장된 캐시를 재사용하게 됨 - 304 응답은 메세지 바디를 포함하면 안되는데, 로컬 캐시를 사용하기 때문
5. PRG( Post/Redirect/Get )
POST로 주문 후 새로고침을 하면 재주문이 될 수 있음( POST으로 보내는 과정 전체가 다시 수행됨 )
따라서 중복 수행될 수 있음, 이를 피하기 위해 PRG 절차를 따르도록 설계
5-1) PRG 사용전
POST로 주문을 넣는 상황
item을 새로 추가하고 200OK 메세지를 서버가 전달
(4)번에서 실수로 사용자가 새로고침을 할 경우 마지막 요청이 POST였기 때문에, 화면 갱신에서 끝이 아닌 새 주문이 다시 들어가게 됨
새 주문이 온 것 처럼 동작
※ 서버 단에서는 주문 고유 id를 생성해 처리상황을 보고 같은 번호로 재 주문이 온다면 막는 형식으로 서버수준에서도 잘못된 주문을 막아야 하고, 클라이언트 수준에서도 중복 주문을 막는 방식이 필요함(아예 재주문 못하도록 설계)
5-2) PRG 사용후
※ 장점
1) 클라이언트 단의 사용자의 사용성이 좋음
- 실수로 refresh해도 재주문이 아니고 주문 결과를 조회하게되고 POST refresh의 경우 경고창이 뜨지만 이런 현상을 제거
2) 서버 입장에서도 재주문을 하는 등과 같은 오류를 줄일 수 있음
POST로 주문 후 새로고침으로 인한 중복 주문 방지
POST로 주문 후, 주문 결과 하면을 GET 메서드로 리다이렉트
새로고침 하여도 결과 화면을 GET으로 조회
중복 주문 대신, 결과 화면만 새로고침해도 GET으로 다시 요청하도록 됨
POST로 요청이 들어가고, 서버는 302 / 303 / 301 등으로 응답(주로 302, 303으로 응답) → GET으로 요청이 변경되고 본문을 날아가는 형식 - 응답으로는 새롭게 생성된 리소스의 URI를 헤더의 Location 항목으로 return, 원래 3xx 메서드 기본적으로 location항목 리턴해줌
GET 메서드로 주문 결과를 조회하도록 되고, 새로고침하여도 주문 결과만 재 조회하는 식으로 중복 주문 문제가 발생하지 않음
5-3) 정리 & 무엇을 써야 하나
6. 4xx / 5xx
6-1) 4xx( Client Error )
(a) 발생 원인
클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
오류의 원인이 클라이언트에 있음
클라이언트가 이미 잘못된 요청 / 데이터를 보내고 있어서 5xx와 다르게 재시도를 하여도 실패하게 되어있음
(b) 응답 종류
400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음 - 요청 구문, 메세지 등등이 오류 - 클라이언트는요청 내용을 다시 검토하고 보내야 함 - ex) 요청 파라미터가 잘못되었거나, API 스펙에 맞지 않는 request인 경우 → 서버 개발자가 모두 막고 있어야 함, 맞지 않는 것은 전부 4xx오류로 보내야 함
401 Unauthorized : 클라리언트가 해당 리소스에 대한 인증이 필요함 - 인증( Authentication ) 되지 않음 - 401 오류 발생시 응답에, WWW-Authenticate 헤더와 함께 인증 방법을 설명하는 응답 보냄 > 참고 - 인증( Authentication ) : 본인이 누군지 서버에 확인, (로그인) - 인가( Authorization ) : 권한 부여( Admin 권한처럼, 특정 리소스에 접근할 수 있는 권한 ) → 인증을 할 시 인가가 될 수 있음 - 인증이 안되었으면 Unauthorized라고 함(*un-authenticated가 아님...!)
403 Forbidden - 서버가 요청을 이해했지만, 승인을 거부함 - 주로 인증 자격 증명은 있지만 인가가 안된 리소스에 접근하여, 접근권한이 불충분한 경우
404 Not Found - 요청 리소스가 서버에 없음 - OR... 403 대신 권한이 없는 리소스 접근에 대해 리소스 존재 여부를 숨기고 싶을 때
6-2) 5xx( Server Error )
※ 5xx 오류 주의
절대로 발생하면 안되는 에러 응답으로 생각해야됨 ex) 고객이 출금 / 고객의 심사 등 500 에러는 문제가 있을 때 내야하는 것으로, 위의 예시들은 500으로 하면 안됨 비지니스 로직상 예외 케이스 들은 500으로 대응하면 안됨
> NULL Point, DB-down 등의 오류일 때 500 에러 띄우기
(a) 발생 원인
서버 문제로 오류 발생
서버에 문제가 있기 때문에, 재시도하면 성공할 수도 있음( 일시적인 장애로 부터 서버가 복구되었을 때 )
(b) 응답 종류
500 Internal Server Error : 서버 문제로 오류 발생, 애매하면 500 오류 - 서버 내부 문제로 발생 - 애매할 경우 사용
503 Service Unavailable : 서비스 이용 불가, 일시적으로 서버 내부 작업해서 서비스 못할 때 - 서버가 일시적 과부하 또는 예정된 작업으로 잠시 요청 처리할 수 없음 - Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음
