아래 주소를 복사하여 친구와 공유하고 요청을 복원하고 인터페이스를 함께 디버그할 수 있습니다!위의 요청, 아래에 있습니다
참고: get 요청의 길이는 제한되어 있으므로 기억하십시오! 길이가 너무 길면 불완전한 정보가 전송될 수 있습니다. 자세한 내용은 Baidu에 문의하십시오.
인터페이스를 빠르게 테스트할 수 있도록 요청 정보를 이 사이트로 보낼 수 있습니다. 이 사이트 형식으로 보내기만 하면 이 사이트의 요청 페이지로 바로 이동할 수 있으므로 수고를 덜 수 있습니다. 자신의 요청을 개발하는 것. !
이 사이트에서 제공하는 주소: http://coolaf.com/tool/gp, 요청 받기 지원, 웹페이지에서 이 사이트로 매개변수 전달
URL은 이 사이트의 요청 상자에 자동으로 채워지므로 직접 테스트하기에 편리합니다. 매개변수 설명은 다음과 같습니다.
u: 요청한 URL, 필수
m: 요청 메소드, 기본 포스트 기타: get, put, delete, head, trace, patch, options
p: 요청한 게시물 매개변수, 선택사항
c: 귀하가 요청한 쿠키, 형식은이 사이트 페이지의 작성 방법과 같습니다. 선택 사항
h: 요청한 헤더, 형식은 이 사이트 페이지의 작성 방법과 같습니다. 선택사항
px: 프록시 IP 사용, 형식 10.10.10.10: 8080, 선택 사항
위의 모든 매개변수는 encodeURIComponent여야 합니다.
예시:
http://coolaf.com/tool/gp?u=http%3A%2F%2Fcoolaf.com%2Ftool%2Fparams%3Fg%3Dgtest%26g2%3Dgtest2&p=p%3Dptest%26p%3Dtest2&c=c%3Dcookie%3Bc1%3Dcookie1%3Bc2%3Dcookie2&px=&h=Content-Type%3Aapplication%2Fx-www-form-urlencoded%0AAccept-Language%3Azh-CN%2Cen-US%3Bq%3D0.8%2Cen%3Bq%3D0.6%2Czh%3Bq%3D0.4
json 데이터를 보낼 수 있도록 http 요청의 헤더에 Content-Type: application/json을 추가합니다.
이 도구에 대한 간략한 설명:
1. 이 온라인 도구는 인터페이스 http post, get, put, delete, head, trace, options, patch 및 기타 요청을 지원하고 쿠키 헤더 및 ip 프록시가 있는 요청을 지원합니다.
2. API 인터페이스 문서를 생성할 수 있으며, 이 사이트는 API 인터페이스 스트레스 테스트 및 웹 소켓 테스트도 제공합니다. 2. 로그인할 인터페이스에 접근할 때 쿠키를 수동으로 입력할 수 있습니다. 또는 Google Chrome에서 이 인터페이스 도메인 이름을 방문하고 네트워크에서 F12를 누르고,
아이콘, 이 도구의 쿠키를 직접 복사하여 입력합니다. 쿠키를 사용하여 방문할 수 있으며 수동으로 입력할 필요가 없습니다.
3. 헤더는 수동으로 입력할 수 있습니다(사용자 정의 헤더 정보). 브라우저의 네트워크에서 헤더 정보를 가져와 이 도구의 헤더 입력 상자에 직접 채울 수도 있습니다.
아이콘
http 요청에 대한 모국어:
http 인터페이스를 테스트하고 사용하려면 먼저 http 요청이 무엇인지 이해해야 합니다.
일반적으로 http 요청은 http 프로토콜을 통해 클라이언트의 것을 서버로 보내는 것이고, 서버는 http 프로토콜의 정의에 따라 클라이언트가 보낸 것을 파싱한다.
여기 뭔가요!
get 및 post 요청 매개변수는 일반적으로 http 요청에 사용되며, get 매개변수는 url 뒤에 연결되며 도메인 이름과 매개변수는 "?"로 연결되어 get 요청을 형성합니다.
예: http://coolaf.com?a=b&c=d, 물음표가 요청 가져오기 매개변수 이후에 게시 요청은 URL에 표시되지 않고 http에 배치됩니다.
요청 본문에서 기능은 모든 주요 언어로 캡슐화되고 요청 후 매개변수는 본문에서 구문 분석됩니다. post 매개변수는 어떻게 생겼습니까? 그것은 될 수 있습니다
어떤 형식이든 공통 key=value 형식은 get 요청 형식 "a=b&c=d"와 동일하며 json 및 xml 형식도 공통입니다. 이것
일부 형식은 전달될 때 Content-Type의 영향을 받습니다. 다른 Content-Type 전달 형식은 다르며 서버는 다음을 기반으로 합니다.
Content-Type은 해당 형식을 분석합니다. 클라이언트와 서버는 이러한 프로토콜을 사용하여 전달되는 형식을 구별합니다. 이해해야 함
Common Content-Type, 자세한 내용은 위의 Content-Type 링크 설명을 참조하십시오.
콘텐츠 유형: application/x-www-form-urlencoded, 양식 양식 및 요청 가져오기 및 게시와 유사합니다.
"a=b&c=d"와 같은 형식을 사용하면 서버가 자동으로 구문 분석합니다.
Content-Type: application/json json 형식을 보내려면 요청 헤더에 이 Content-Type을 추가해야 합니다.
유형의 경우 이 형식의 서버에 대한 승인이 동일하지 않으며 일반적으로 사후 요청으로 구문 분석되지 않으며 일반적으로 본문 스트림을 읽어 가져와야 합니다.
위의 두 가지 일반적인 전송 형식입니다. 때로는 코드를 직접 작성할 때 작성할 필요가 없습니다. 일부 라이브러리는 자동으로 추가되어 있기 때문에
직접 추가할 필요가 없습니다. Content-Type은 매우 중요합니다. 전달하는 형식에 영향을 줍니다.
또한 http 요청에서 헤더는 요청 헤더와 응답 헤더로 구분되며 요청 헤더에주의하십시오.
클라이언트가 요청할 때 전송되어 클라이언트의 상황, 서버가 사용자에게 어떻게 반환해야 하는지(예: 압축 여부)를 서버에 알려줍니다.
(Accept-Encoding: gzip, deflate, sdch) 이것은 내가 이러한 종류의 압축을 지원한다는 것을 서버에 알리는 것입니다.
나중에 데이터 압축의 종류를 선택할 수 있습니다. 잠금을 해제할 수 있습니다. 캐시 여부, 허용 언어, 사용자 에이전트, 참조자 등이 있습니다.
쿠키는 또한 요청 헤더에 배치되고 로그인을 활성화하기 위해 서버에 전달됩니다. 그래서 요청 헤더는
서버 측에 어떤 것이 있거나 전달할 매개변수가 있는지, 위의 사항은 모두 http 프로토콜에 의해 정의되며 이 규칙에 따라 모든 사람이 이를 구문 분석할 수 있습니다.
헤더는 사용자 정의할 수 있으며 모든 변수를 추가할 수 있습니다. 따라서 헤더의 정보를 임의로 수정하여 다음 주소로 보낼 수 있습니다.
서버 측에서.
응답 헤더는 서버가 클라이언트에 제공하는 정보인 요청 헤더와 관련이 있으며 일부는 클라이언트를 기반으로 합니다.
요청에 대한 응답, 일부 서버는 클라이언트에게 다른 정보(예: 요청 프로토콜, 요청 상태 코드, 캐시 여부,
쿠키 설정은 응답 헤더에도 반환되며 브라우저는 쿠키를 받으면 브라우저에 설정합니다.
모국어가 너무 많아서 실수나 문제가 있으면 그룹에서 토론할 수 있습니다. 배움은 끝이 없습니다. http는 마법이 아닙니다. 브라우저의 f12를 더 많이 활용하고,
네트워크를 보면 시간이 지남에 따라 예상치 못한 효과가 나타날 것입니다! ! !