REST API 베스트프랙티스: 쿼리 문자열의 arg와 요구 본문의 arg

REST API 베스트프랙티스: 쿼리 문자열의 arg와 요구 본문의 arg

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에 넣을 수 있습니다.

제가 항상 써왔던 이유는POST,PUT,그리고.PATCH고객이 독자적으로 생각할 수 있는 정보를 포함한 payload를 가지고 있을 가능성이 높기 때문에 이러한 메서드의 모든 payload를 URL이 아닌 요청 본문에 넣는 것이 가장 좋습니다.어디선가 어떤 식으로든URL 텍스트가 웹 서버에 의해 기록되고 있으며 로그 파일 시스템에 일반 텍스트로 분산되는 것을 원하지 않습니다.

URL을 통한 잠재적 노출은 문제가 되지 않습니다.GET또는DELETE또는 다른 REST 작업도 가능합니다.

언급URL : https://stackoverflow.com/questions/25385559/rest-api-best-practices-args-in-query-string-vs-in-request-body