RESTful API가 파일 또는 위치 만 리턴 할 수 있어야합니다.


12

이것은 잠시 동안 나를 수수께끼로 만들었습니다.

예를 들어, 시스템에 기본 컨텐츠를 제공하고 JSON을 소비 및 생성하는 REST API가 있습니다. 이 엔드 포인트에서 그림 및 설명에 대한 URL을 생성하며 다음과 같이 찾을 수 있습니다. // localhost / myApi / pictures / 1

{
    id: 1,
    description: "This is a pretty picture of a daisy",
    URL: <OUR URL>
}

이제 OUR_URL은 API의 위치를 ​​가리켜 야합니다 (예 : // localhost / myApi / files / pictures / 1). JPG를 반환합니다 (API 뒤의 응용 프로그램은 파일의 실제 내용을 읽고 클라이언트로 다시 스트리밍합니다). ). 이것은 JSON 응답을 생성하는 나머지 API와 분명히 다르며 실제 파일을 읽고 스트리밍하는 데 오버 헤드가 발생합니다.

또는 OUR_URL이 REST 서비스 범위를 벗어난 URL을 가리켜 야하므로 //localhost/files/pictures/1.jpg 파일을 직접 읽는 위치입니다.

따라서 질문은 다음과 같습니다.

RESTful API가 파일 또는 위치 만 리턴 할 수 있어야합니까?


1
REST가 무엇인지에 대한 일반적인 설명이 "클라이언트가 URL에 요청을하고 서버가 물건을 반환"한다는 사실을 알고 있습니까? 전체 아이디어는 REST가 매우 느슨하게 정의되어 있으며 거의 ​​모든 URL 기반 검색 체계에 적용 할 수 있다는 것입니다.

답변:


17

RESTful 서비스는 API 사용자 에게 리소스 를 제공해야합니다 . 리소스는 JSON 또는 XML에서 JPEG 및 HTML에 이르는 다양한 형식을 가질 수 있습니다.

단일 API가 단일 형식의 리소스에만 서비스를 제공해야한다는 요구 사항이나 기대조차 없습니다. URI에서 JSON 문서를 제공하고 URI /myApi/pictures/1에서 JPEG 파일 을 제공하는 데 아무런 문제가 없습니다 /myApi/files/pictures/1.
더 극단적 인 경우 요청자가 요청한 형식에 따라 동일한 URL에서 JSON 설명과 JPEG 파일을 모두 제공 할 수도 있습니다.


7

URI를 반환하는 데있어 한 가지 문제는 일반 오래된 파일 서버가 보안을 수행 할 수 없다는 것입니다. 따라서 파일에 액세스 할 수있는 사용자에 대해 제한을 수행해야하는 경우 REST API에서 직접 파일을 리턴 할 수 있어야합니다 (또는 사용자에게 권한이없는 경우 파일은 올바른 상태가 아님 등).

그렇지 않으면 평범한 기존 URI를 반환하고 전용 CDN으로 보내면 프로비저닝, 단순성 및 확장성에 많은 이점이 있습니다.


인증 측면은 내가 생각해 본 적이없는 매우 좋은 점입니다.
Crazy Dino
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.