Http day2

put

리소스 대체 

없으면 생성 있으면 완전 대체 (기존거 다 사라짐)

클라이언트가 리소스의 위치를 알고 지정(post)는 모름

 

 

patch - 부분변경(지원이안대기도 함)

 

delelte - 삭제 

 

 

 

매서드 속성 

안전 - 리소스를 변경하지 않는다 

 

멱등(외부 요인까지는 고려하지 않음)

몇번을 호출하든 결과가 똑같다 

post만 아님 - 두번 결제하면 중복 결제 >> 자동 복구 메커니즘(멱등일시 일정시간 응답 없으면 재요청)

put - 계속 덮어서 멱등임

del - 계속 지워서 멱등임

get - 계속 가져와도 멱등임

 

캐시 가능성

- get head post patch 만 캐시가능

실제로는 get head만 주로 사용 사실상 get 원툴

 

 

쿼리 파라미터 데이터 전송

get 정렬필터 

 

메시지 바디 

post put patch 

 

 

정적 데이터 조회

경로를 넣으면 리소스를 받음

get 

 

동적 데이터 조회 > 쿼리파라미터 사용

검색어나 정보등을 쿼리에 넣어서 전송함

 

Html 폼 전송 

form 에 대이터를 인코딩하여 전송

주의! get 사용시 쿼리 파라미터에 들어가기 떄문에 정보가 노출 될 수도 있음

multipart/formdata  > 이미지 전송시 (바이트로 이루어진) 바운더리로 나누어서 컨텐츠별로 구역이 나뉘어 보내짐

(get post 만 지원)

 

api 전송

json같은걸로 통쨰로 넘김 개꿀(xml)

서버간 통신시, 앱클라이언트, 웹클라이언트(ajax), post put patch 활용 가능

 

 

 

컬렉션 - 서버가 관리하는 uri

 

put 사용시 리소스 uri를 알고있어야함(스토어 - 클라이언트가 관리하는 리소스 저장소)

post는 자체적으로 uri를 관리 

 

 

문서 - 단일 개념 

컬렉션 - 서버가 관리하는 리소스 디렉터리 > 대부분 사용

스토어 - 클라이언트가 관리하는 자원저장소(파일, 게시판)

컨트롤러 - 컨트롤 유얼아이 (동사사용)

 

 

상태코드

1 처리중 - 사용 잘 안함

2 성공 

200 성공 << 거의 이것만 사용함 

201 추가됨 < 가끔 쓰기도 함

202 보류 (오래 거릴떄> 백엔드에서 처리하는대 시간 걸림) 

204 성공했지만 본문에 보낼 데이터가 없음(save)

 

3 추가행동 필요

- 리다이렉션 301 주소가 바뀌면 자동으로 바뀐 url 을 보내주면서 새로운 패이지로 이동됨

>영구적 301 - get으로 변하고 본문삭제  308 본문 유지

>일시 - 주문완료후 주문 내역

302  get으로 변하고 본문 삭제 아마 

307 본문유지 포스트 유지

303 겟으로 변경 확정

>특수 - 결과 대신 캐시

prg

주문후 새로고침  > 중복요청?

요청 > 302 > get으로 완료페이지를 다시 보여줌

 

300 - 안씀

304 - 캐시를 목적으로  - 리소스가 수정되지 않음을 전달 > 클라가 캐시를 재사용 (바디 없음 < 로컬 써야함)

4 클라이언트 잘못

재시도 해도 같은 결과

400 잘못된 요청

401 인증되지 않음 인증(로그인) 인가(권한) 를 알려줌 

403 인증 자격은 있지만 권한이 없는 경우 

404 리소스가 없을때 

5 서버 잘못(나오면 안됨) 비지니스 로직상 문제가 아님 디비가 내려가는등의 심각한 문제만 다룸

재시도 하면 작동할 여지가 있음

500 < 대부분 서버 내부에 문제가 있음 

503 서버 과부하