REST API 모범 사례 : 쿼리 문자열의 인수와 요청 본문의 인수

REST API는 여러 위치에 인수를 가질 수 있습니다.

1. 요청 본문 에서-json 본문의 일부 또는 기타 MIME 유형
2. 에서 쿼리 문자열 - 예를 들어,/api/resource?p1=v1&p2=v2
3. URL 경로의 일부로 -예/api/resource/v1/v2

위의 1과 2 중에서 선택하는 모범 사례와 고려 사항은 무엇입니까? 여기서는
2 대 3을 다룹니다 .

위의 1과 2 중에서 선택하는 모범 사례와 고려 사항은 무엇입니까?

일반적으로 콘텐츠 본문은 서버에 업로드 / 다운로드 할 데이터에 사용되며 쿼리 매개 변수는 요청 된 정확한 데이터를 지정하는 데 사용됩니다. 예를 들어 파일을 업로드 할 때 본문에 이름, MIME 유형 등을 지정하지만 파일 목록을 가져올 때 쿼리 매개 변수를 사용하여 파일의 일부 속성별로 목록을 필터링 할 수 있습니다. 일반적으로 쿼리 매개 변수는 데이터가 아닌 쿼리의 속성입니다.

물론 이것은 엄격한 규칙이 아닙니다. 당신은 당신에게 더 적합하고 작동하는 방식으로 그것을 구현할 수 있습니다.

쿼리 문자열 , 특히 처음 두 단락에 대한 위키피디아 문서 를 확인할 수도 있습니다 .

POST / PUT 요청에 대해 이야기하고 있다고 가정합니다. 의미 상 요청 본문에는 게시하거나 패치하는 데이터가 포함되어야합니다.

URL (URI)의 일부인 쿼리 문자열은 게시하거나 패치하는 리소스를 식별하기 위해 존재합니다.

의미 체계를 따르는 것이 내 모범 사례를 요청했습니다. 물론, 당신이 사용하는 웹 프레임 워크가 이것을 매개 변수 로 추상화한다면 당신의 경험 법칙을 사용하는 것이 효과가있을 것 입니다.

당신은 가장 잘 알고 있습니다 :

• 일부 웹 서버에는 URI 길이에 제한이 있습니다.
• CURL을 사용하여 요청 본문 내에서 매개 변수를 보낼 수 있습니다.
• 데이터를 보내는 위치는 디버깅에 영향을 미치지 않아야합니다.

다음은 내 경험의 규칙입니다 ...

바디 사용시기 :

• 인수에 플랫 키 : 값 구조가없는 경우
• 직렬화 된 바이너리 데이터와 같이 값이 사람이 읽을 수없는 경우
• 매우 많은 수의 인수가있을 때

쿼리 문자열을 사용하는 경우 :

• 인수가 디버깅하는 동안보고 싶을 때
• 코드를 개발하는 동안 수동으로 호출 할 수 있도록하려면 curl
• 여러 웹 서비스에서 인수가 공통적 인 경우
• 다음과 같은 다른 콘텐츠 유형을 이미 보내는 경우 application/octet-stream

믹스 앤 매치를 할 수 있습니다. 공통된 것을 쿼리 문자열에 넣고 나머지는 json에 던집니다.