REST API : 사용자 지정 HTTP 헤더와 URL 매개 변수

96

REST API의 요청 부분에서 사용자 지정 HTTP 헤더를 언제 사용합니까?

예:

당신은 사용 하시겠습니까

GET /orders/view 
(custom HTTP header) CLIENT_ID: 23

대신에

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

http rest

— 바 실레 코토 바누
소스

123

URL은 리소스 자체를 나타냅니다. "클라이언트"는 조치를 취할 수있는 리소스이므로 기본 URL의 일부 여야합니다 /orders/view/client/23.

매개 변수는 리소스에 대한 액세스를 매개 변수화하기위한 것입니다. 이것은 특히 게시물 및 검색과 함께 작동 /orders/find?q=blahblah&sort=foo합니다. 매개 변수와 하위 리소스 사이에는 미세한 경계가 /orders/view/client/23/active versus /orders/view/client/23?show=active있습니다.. 하위 리소스 스타일을 권장하고 검색을 위해 매개 변수를 예약합니다.

각 엔드 포인트는 상태 전송 (니모닉을 조작하기 위해)을 나타내므로 사용자 지정 헤더는 리소스 이름 (URL), 리소스 상태 (본문) 또는 매개 변수를 직접 포함하지 않는 항목에만 사용해야합니다. 리소스 (매개 변수)에 영향을줍니다. 그러면 사용자 지정 헤더 요청에 대한 진정한 메타 데이터가 남습니다.

HTTP에는 필요한 모든 것을 포함하는 매우 광범위한 헤더가 있습니다. 사용자 지정 헤더가 나타나는 곳은 사용자를 대신하여 작동하는 시스템 대 시스템 요청입니다. 프록시 시스템은 사용자의 유효성을 검사하고 X-User: userid헤더에 " "을 추가 하고 시스템 자격 증명을 사용하여 엔드 포인트에 도달합니다. 수신 시스템은 시스템 자격 증명이 사용자를 대신 할 권한이 있는지 확인한 다음 사용자가 작업을 수행 할 권한이 있는지 확인합니다.

— Nialscorva
소스

포괄적 인 답변에 감사드립니다! (헤더를 제거하는) 악의적 인 프록시를 가질 위험이 여전히 높은 모바일 API에 대해 X-User를 계속 사용 하시겠습니까?

— Vasile Cotovanu 2012

1

아니요, 제가 언급 한 X-User의 사용은 시스템이 제 3자를 대신하여 작동하는 시스템 간 연결에 있습니다. 예를 들어 사용자 U는 서버 A와 통신합니다. 서버 A는 X-User 헤더와 함께 서버 B에 자격 증명을 제공하여 "사용자 U를 대신하여이 작업을 수행 할 권한이 있는지 확인하려면 내 자격 증명을 사용합니다."라고 말합니다. 이는 서비스 지향 아키텍처에서 발생하며 일반적으로 HTTPS를 사용합니다. 모바일 플랫폼은 거의 항상 사용자 자신이 행동해야하며 거래에 적절한 1 인칭 자격 증명을 사용해야합니다.

— Nialscorva 2012

7

세 번째 단락은 내가 읽은 가장 유익한 답변 중 하나입니다 ;-)

— Alistair77

1

@Nialscorva 좋은 설명! 사용자가 승인 된 컨테이너 (예 : 모바일 앱)를 통해 내 API와 상호 작용하도록하려면 어떻게해야합니까? 내가 지금하고있는 것은 내 모바일 앱이 자체적으로 어떤 작업도 수행 할 권한이 없으며 최종 사용자도 마찬가지입니다. 사용자가 작업을 수행하려는 경우 두 자격 증명이 모두 있어야합니다.

— bolbol 2013-06-03

6

사용자 정의 헤더에는 다음과 같은 장점이 있습니다.

네트워크 도구 / 스크립트 (인증, 메타 정보 등)로 쉽게 읽을 수 있습니다.
보안 항목이없는 URL을 유지합니다 (브라우저 / 프록시 캐시가 아닌 안전함).
URL을 깔끔하게 유지 : 리소스 캐싱을 개선 할 수 있습니다.

— 크리스토프 루시
소스

그들은 또한 자동 / 프록시에 의해 필터링 스트립 핑 될 수있다

— FUSI

@fusi 좋은 점 ... 여기에 대한 주제가 있습니다 : stackoverflow.com/questions/20820572/…

— Christophe Roussy

5

표준 또는 규칙에 따라 정보를 전달할 다른 방법이 없을 때만 사용자 지정 헤더를 사용합니다. Darren102는 그 값을 전달하는 일반적인 방법을 설명합니다. Api는 사용자 지정 헤더를 사용하는 일반적인 패턴을 사용하여 훨씬 더 친숙해질 것입니다. 즉, 사용할 사례가 없다는 것은 아니며, 마지막 수단이어야하며 HTTP 사양에 의해 아직 처리되지 않은 것이어야합니다.

— 고소
소스

전적으로 동의합니다. 작업을 수행하는 표준 방법이 있다면 바퀴를 다시 발명하지 마십시오.

— Alessandro Santini

5

REST API의 요청 부분에서 언제 ... HTTP 헤더를 사용합니까?

인증 : GUID, 기본 인증, 사용자 지정 토큰 등. 예 : 사용자 이름 / 암호 대신 REST API 용 Guid 토큰을 사용한 기본 인증

PCI-DSS 또는 기타 보안 규칙이 적용되는 도메인간에 토큰 또는 기타 인증과 같은 정보를 전달하는 데 관여하는 경우 일부 규정에서는 인증 요소가 사소하게 재생 될 수있는 URL에서 벗어나도록 명시 적으로 요구하기 때문에 매개 변수를 묻어 야 할 수도 있습니다. 브라우저 기록, 프록시 로그 등).

— user3038458
소스

1

REST에 대한 표준은 없지만 허용되는 방법은 다음과 같습니다.

GET /orders/view/23

사용자 정의 헤더를 사용하지 않으므로 23 after view는 id라고 가정하므로 id를 취하여 해당 정보를 생성하는 함수를 갖게됩니다.

— darren102
소스

1

프록시가 전달하는지 여부를 알 수 없으므로 사용자 지정 헤더를 사용하지 않습니다. URL 기반은 갈 길입니다.

GET / orders / view / client / 23

— 안토니 스콧
소스

1

커스텀 헤더도 권장하지 않지만 깨진 프록시가 이유가 아닙니다. 프록시가 손상되었으므로 수정해야합니다.

— Julian Reschke 2012

1

확실히 OK :

GET /orders/view/client_id/23 or 
GET /orders/view/?client_id=23

또한 확인 :

GET /orders/view/23 or

나는 이것도 괜찮을 것이라고 생각합니다.

POST /orders/view 
(custom HTTP header) CLIENT_ID: 23

— paulsm4
소스

REST-ful POST 응답은 "/ orders / view / 23"과 같이 Location 헤더가 설정된 HTTP 303이어야합니다.

— Rich Remer

0

Enveloping 이 좋은 방법이 아니라는 점을 고려하여 사용자 지정 헤더를 사용하여 부분적으로 처리 된 요청에 대한 추가 정보를 포함 할 수 있습니다 . 헤더는 안전 합니다.

— 안와르 후사인
소스