개술 HTTP 표준 에 따라 HTTP 요청 은 여러 가지 요청 방법 을 사용 할 수 있 습 니 다.
HTTP 1.0 은 세 가지 요청 방법 을 정의 했다. 헤드, get, post 방법 이다.
HTTP 1.1 은 put, delete, options, trace, connect 방법 등 다섯 가지 요청 방법 을 추가 했다.
간단 한 요청 과 예비 검사 요청 1. 간단 한 요청 HTTP 1.0 세 가지 방법: HEAD, GET, POST 기본 값 은 간단 한 요청 Simple Request 에 속 합 니 다.
사용자 정의 헤더 가 없습니다
MIME Type in text/plain、multipart/form-data、application/x-www-form-urlencoded
2. 예비 검사 요청 사전 검사 요청 Priflight Request 는 요청 하기 전에 브 라 우 저 에서 옵션 요청 을 자발적으로 보 내야 합 니 다.예비 검사 요청 은 OPTIONS 요청 으로 서버 에 권한 정 보 를 요청 하 는 데 사 용 됩 니 다.예비 검사 요청 이 성공 적 으로 응답 한 후에 야 실제 요청 을 하고 실제 데 이 터 를 휴대 할 수 있 습 니 다. 예비 검사 요청 범위 일반 HTTP 1.1 의 방법 은 기본적으로 사전 검사 요청 을 실행 합 니 다. 그러나 간단 한 요청 은 다음 조건 을 만족 시 키 면 Options 요청 을 촉발 할 수 있 습 니 다.
사용자 정의 헤더 정보 가 있 음
MIME Type Not in text/plain、multipart/form-data、application/x-www-form-urlencoded
각 요청 방법 소개 Get 1. 방법의 용도
GET 방법의 첫 번 째 목적 은 자원 획득
이다. 2. 방법 특징 a) 매개 변 수 를 볼 수 있 습 니 다.
GET 방법의 매개 변 수 는 URL 에 명시 적 으로 포함 되 어 있 기 때문에 민감 한 정 보 는 GET 방법
을 사용 하 는 것 을 권장 하지 않 습 니 다.
그러나 이 때문에 GET 방법 은 책 갈피 저장
을 허용 합 니 다. b) 데이터 형식 은 ASCII 만 허용
GET 방법의 데이터 형식 은 ASCII 문자 만 허용 되 므 로 바 이 너 리 파일 을 전달 하 는 데 GET 방법 을 사용 하면 안 됩 니 다
c) 책 갈피 저장 가능
우리 가 특정한 사 이 트 를 방문 하 는 빈도 가 매우 높 을 때 반드시 책 갈피 에 추 가 될 것 이다. 그러면 책 갈 피 는 GET 방법 으로 저장 하 는 것 이다
. d) 캐 시 가능
GET 방법 은 캐 시 를 지원 합 니 다. 이번 요청 이 캐 시 를 허용 할 때 자원 저장 값 을 로 컬 cache 로 만 료 되 지 않 은 상태 에서 로 컬 cache 를 직접 가 져 옵 니 다.캐 시 만 료 후 상황 을 보고 정 합 니 다
e) 매개 변 수 는 브 라 우 저 기록 에 유 지 됩 니 다.
비교적 직관 적 인 느낌 은 브 라 우 저의 역사 기록 에서 검색 한 키워드 정보
를 볼 수 있다 는 것 이다. f) 요청 길 이 는 사용 하 는 브 라 우 저 와 서버 에 제 한 됩 니 다.
서로 다른 브 라 우 저 는 GET 요청 길이 에 대한 제한 도 다 릅 니 다. 이것 은 브 라 우 저 / 서버 (IE, Chrome, Apache, IIS 등) 의 길이 에 대한 제한 이지 HTTP 프로 토 콜
이 아 닙 니 다. Post 1. 방법의 용도
POST 방법의 첫 번 째 목적 은 제출 이 고 POST 방법 은 보통 자원 추가
에 사용 된다. 2. 방법 특징 a) 매개 변 수 는 보이 지 않 고 저장 되 지 않 습 니 다.
그래서 POST 방법 은 책 갈피 가 저장 되 어 서 는 안 된다
b) 책 갈피 로 저장 불가
이 유 는 위 와 같다
c) 캐 시 되 지 않 음
제 가 제출 하고 자 하 는 데이터 가 로 컬 cache 에 캐 시 되 어 있 습 니 다. 생각해 보 니 일리 가 없습니다
d) 브 라 우 저 기록 에 저장 되 지 않 습 니 다.
역시 매개 변수 가 보이 지 않 기 때문이다
e) 요청 길이 제한 없 음
POST 방법 과 같은 제출 을 최 우선 목적 으로 하 는 방법 은 요청 길 이 를 제한 할 수 없 을 것 이다
. f) 데이터 형식
제한 이 없 기 때문에 POST 는 서버 에 파일 을 제출 할 수 있다
g) 요청 방식
POST 요청 은 GET 요청 과 달리 HEAD 정 보 를 먼저 제출 하고 100 응답 을 받 아야 다시 데이터 제출
Head 1. 방법의 용도
HEAD 방법 은 헤더 정 보 를 얻 는 데 사 용 됩 니 다. 예 를 들 어 cache 가 수정 되 었 는 지, 기한 이 지 났 는 지 확인 하 는 데 사 용 됩 니 다.
2. 방법의 특징
HEAD 방법 은 GET 방법 과 유사 하지만 응답 주체
로 돌아 가지 않 습 니 다. Options 1. 방법의 용도
OPTIONS 방법의 첫 번 째 목적 은 Priflight Request
이다. 2. 방법 특징 현재 다음 설정 이 있다 면:
Access-Control-Allow-Methods：OPTIONS, PUT
그러면 브 라 우 저가 Priflight Request 를 시작 하면 허 용 된 HTTP 방법 에 만 포 함 된 요청 이 통 과 됩 니 다 (Simple Request 제외). 예 를 들 어 Delete 는 Options 이후 요청 되 지 않 습 니 다. Put 와 Patch 1. 방법의 용도
Put 와 PATCH 방법 은 모두 자원 업데이트 에 사용 된다
2. 방법의 특징
Put: 배경 에서 Put 방법의 매개 변 수 는 완전한 자원 대상 으로 대상 의 모든 필드
를 포함 합 니 다.
Patch: 배경 에서 Patch 방법의 매개 변 수 는 우리 가 수정 해 야 할 자원 대상 의 필드 만 포함 합 니 다
Delete 1. 방법 용도 Delete 방법 은 일반적으로 자원 삭제 에 사 용 됩 니 다. 방법 과 규범 사실 우 리 는 모두 Post (증) Delete (삭제) Put (고 쳐) Get (조사) 이 라 고 말 하지만 사실은 우리 가 어떻게 방법 을 실현 하 는 지 는 자 유 롭 습 니 다. 즉, 당신 은 Get 으로 자원 을 삭제 하고 Delete 로 자원 을 증가 할 수 있 습 니 다. 그래서 아직 이해 하지 못 한 친구 들 이 여기에 오 면 석연 합 니 다. 규정 은 죽 었 고 사람 은 살 았 지만 규정 에 따라 좋 습 니 다.규정 에 따 르 지 않 아 도 된다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
