JSON.stringfy()와 qs.stringfy()의 차이점과 post/get의 매개변수 형식

요청 후 application/json 및 application/x-www-form-urlencoded in axios

Front-end에서 Back-end로 데이터를 전송할 때 get 전송이면 url 뒤에 바로 전송하고, post 전송이면 request body에서 전송한다.
본문에는 두 가지 데이터 형식이 있습니다. 하나는 json 데이터 형식이고 다른 하나는 문자열입니다. 사용할 형식은 백엔드 입력 매개변수의 형식에 따라 다릅니다.
 

 백엔드가 json 데이터 유형을 수신하는 경우 게시물의 헤더를 { 'content-type': 'application/json' }으로 설정해야 하며 백엔드로 전달되는 데이터는 { 'name':' 형식입니다. edward', 'age':'25 ' } 
백엔드가 (form) 문자열 유형을 수신하는 경우 게시물의 헤더를 { 'content-type': 'application/x-www-form-urlencoded' } , 백엔드로 전송되는 데이터는 'name =edward&age=25' 형식입니다. 
 

 qs.stringfy()

axios의 기본 데이터 형식은 json이므로 다음과 같습니다.
1. 백엔드가 json 형식의 데이터를 수신해야 하는 경우 게시 요청 헤더는 요청 헤더를 설정할 필요가 없으며 데이터 형식은 변환할 필요가 없습니다(만약 2.
백엔드가 문자열 형식으로 데이터를 수신해야 하는 경우 게시 요청 헤더에 대해 { 'content-type': 'application/x-www-form-urlencoded' }를 설정해야 합니다. 이번에 전달하는 입력 매개변수가 js
객체인 경우 qs를 사용하여 데이터 형식을 변환해야 합니다.

 

 JSON.stringfy()와 qs.stringfy()의 차이점

let data = { name: 'edward', age: '25' }
前者:JSON.stringfy(data) // ”{ 'name' : 'edward' , 'age' : '25' }”
后者:qs. stringfy(데이터) // '이름=에드워드&나이=25'

 직렬화에 qs를 사용하는 경우 (참고: qs.stringify()는 개체를 &로 접합된 URL 형식으로 직렬화합니다. axios를 설치한 후 qs를 사용할 수 있습니다.)

그런 다음 콘텐츠 유형은
종종 양식 제출이라고 하는 application/x-www-form-urlencoded이고 전송 스타일은 formdata입니다.


컨텐츠 타입

Content-Type은 http/https가 서버에 정보를 보낼 때 콘텐츠 인코딩 유형을 말하며, contentType은 전송되는 데이터 스트림의 유형을 나타내는 데 사용되며 서버는 인코딩 유형에 따라 특정 구문 분석 방법을 사용하여 데이터를 가져옵니다. 데이터 스트림.

네트워크 요청에서 일반적으로 사용되는 콘텐츠 유형은 다음과 같습니다.
공통 페이지 리소스 유형: text/html, text/plain, text/css, text/javascript, image/jpeg, image/png, image/gif, ajax 요청, 일반적
으로 양식 제출 또는 파일 업로드에 사용되는 리소스 유형: application/x-www-form-urlencoded, multipart/form-data, application/json, application/xml 등

인터페이스 데이터 전송 방식  형식 데이터, 페이로드 

 페이로드 콘텐츠 유형: 'application/json; charset=utf-8'
양식 데이터 콘텐츠 유형: 'application/x-www-form-urlencoded'

POST 제출 데이터는 2가지 데이터 전송 방식이 있는데 브라우저는 Content-Type으로 이 2가지 방식을 구분하여 application/x-www-form-urlencoded이면 formdata, application/json 또는 multipart이면 /form -data, 요청 페이로드입니다.

GET 요청인 경우 쿼리 문자열 매개변수

 매개변수를 직렬화하기 위해 qs를 사용해야 하는지 여부는 전적으로 백엔드가 데이터를 받아들이는 방식에 달려 있습니다.

게시물은 qs.stringify를 사용해야 하지만 get 요청에는 사용할 수 없습니다.

서로 다른 요청 방식을 사용할 때 매개변수 전송 방식은 다르지만 서버가 인터페이스의 요청 매개변수를 획득하기 위해 사용하는 방식은 실제로 동일하며 모두 request.getParameter(key)에 의해 획득됩니다. Tomcat은 중간에 요청 파라미터를 파싱 처리하고 파싱된 폼 파라미터를 처리 후 요청 파라미터 맵에 넣기 때문에 백엔드는 request.getParameter(key)를 통해 균일하게 데이터를 얻을 수 있고, Tomcat은 'contentType'을 파싱합니다. 현재 요청이 게시 요청임을 알기 위해 'contentType'이 "application/x-www-form-urlencoded"인 경우 요청 본문 데이터를 읽습니다.
객체를 URL로 직렬화하기 위해 Qs.stringify()를 사용하는 이유:
사후 요청 매개변수는 키-값 쌍의 형태로 요청 본문에 저장되고 Qs.stringify()는 들어오는 객체를 키-값 쌍으로 변환하는 데 사용됩니다. .

레코드 출처: qs.stringify는 HTTP 요청 Content-Type 및 axios의 게시에 필요하지만 get requests_axios에는 필요하지 않음 get qs_JackieDYH's Blog-CSDN Blog 

추천

출처blog.csdn.net/m0_57033755/article/details/130384351