2008-10-21 2 views
4

GET/POST/SOAP를 통해 호출 할 수있는 ASP.NET 웹 서비스로 구성된 API가 있습니다.webservice를 통해 파일을받는 가장 좋은 방법은

새로운 기능을 사용하려면이 웹 서비스를 통해 파일을 받아야합니다. 기본적으로 나는 사용자가 브라우저를 기반으로하는 관리 시스템에 로그인하여 API를 통해 파일 보관소에 파일을 업로드 할 수 있도록 허용하고 있습니다.

API는 가능한 한 쉽게 소비되어야합니다. PHP 클라이언트는 주로 GET/POST 메서드를 사용하기 때문에 SOAP 지원을 중단 할 생각입니다. .NET 클라이언트는 어느 쪽이든 상관 없습니다. 이를 전제 조건으로 간단히 UploadFile (fileName) 메소드를 작성하고 사용자가 POST를 통해 파일을 일반 파일 업로드로 보내야한다고 생각합니다.

그러나 파일 필드를 메서드의 매개 변수로 지정할 수 없습니까? 그래서 "파일"이라는 POST 필드에 파일을 보내야한다고 문서에 명시되어 있다면 파일을 읽을 때 문제가 생길 수 있습니까?

모든 파일은 이진 형식, PDF 파일, 다양한 이미지 형식, FLV 등으로되어 있습니다. 또한 파일 크기는 주로 2-20MB 부근이지만 위의 해결 방법을 고려할 때 250MB 영역의 파일을 수락하는 데 문제가 있습니까?

이 방법으로 파일을 받으면 디스크에 쓰기 전에 파일이 메모리에 완전히로드됩니다. 서비스가 스트림을 수신하게하여 다른 매개 변수를 수락하지 못하도록하는 것 외에 다른 방법이 있습니다. 그리고 서비스의 쉬운 사용을 방해합니까?


는 내 옆에 무엇이 가능한지 게다가, 나는 호출 수신자가 파일을 전송하는 나는 가능한 한 쉽게하는 방법에 관해서도 궁금합니다. 나는 POST가 파일을받는 가장 접근하기 쉬운 방법 중 하나라고 추측하고 있지만 누구나 의견이 있으면 그 내용도 듣고 싶습니다.

답변

1

그러나 파일 필드를 메서드의 매개 변수로 지정할 수 없습니까? 그래서 "파일"이라는 POST 필드에 파일을 보내야한다고 문서에 명시되어 있다면 파일을 읽을 때 문제가 생길 수 있습니까?

POST (또는 GET) 매개 변수를 추가로 포함 할 수있는 이유가 없습니다. 아마도 파일 이름을 추가 POST 매개 변수로 취할 것이기 때문에 요청에서 로컬 파일 이름을 자동으로 사용하는 클라이언트는 쉽게 이름을 바꿀 수 있습니다. 명명 충돌이 예상된다면 갈등 발생시 서버 선택 이름을 반환 할 수도 있습니다 ... REST 사람들이 일종의 HTTP Created 상태 코드를 사용한다고 생각합니다.

모든 파일은 이진 형식, PDF, 다양한 이미지 형식, FLV 등으로되어 있습니다. 또한 파일 크기는 주로 2-20MB 부근이지만 위의 해결 방법을 고려할 때 250MB 영역의 파일을 수락하는 데 문제가 있습니까?

web.config에서 maxRequestLengths 및 executionTimeouts를 조정해야합니다. 누구나 전화 접속으로 250MB 업로드를 시도한다면 잘 작동하지 않을 것이라고 가정 해 봅시다.

I 디스크에 기록하기 전에 파일을 초래할 것이다이 방법은 완전히 메모리에로드되는 파일 받기 -이 주변에 어떤 방법이, 서비스를시키는 외에 다른 수용에서 저를 해제하여 스트림을 수신하고 매개 변수 및 서비스의 쉬운 사용을 방해합니까?

ASP.NET 2.0+ 스풀은 들어오는 파일을 디스크에 업로드하여 전체 요청을 RAM에 미리로드하지 않도록합니다. 속도와 메모리 사용의 균형을 맞추기 위해 web.config의 requestLengthDiskThreshold을 조정하십시오. 원하는 경우 스트림을 가져갈 수 없습니다. 바이트 배열로 가져올 수는 있지만. 난 그게 무슨 뜻인지 정말 모르겠다 ....

작은 파일 들어, 당신은 클라이언트를 위해 하찮은해야베이스 64 할 수 있습니다. 그러나 20MB의 경우 오버 헤드가 그만한 가치는 없습니다.

기본적으로 Begin_Request를 HttpModule로 연결하고 모든 멀티 파트/양식 업로드에 대한 요청 스트림을 차단하는 다양한 ASP.NET 파일 업로드 구성 요소가 있습니다. ASP.NET 2.0에서는 일종의 진행 콜백 또는 뭔가를 제공하고 싶지 않으면이 작업이 불필요합니다. 그렇다면 웹 서비스의 메커니즘이 동일해야합니다.

RFC 1867이 관련 사양이지만이 upload component은 자신의 구문 분석에 대한 의도가있는 경우 요청이 어떻게 보이는지 레이아웃하는 작업을 잘 수행합니다.

클라이언트의 http 라이브러리에서 multipart/form-data에 대한 지원 수준이 무엇인지 묻습니다. 나는 그것이 주위에 꽤 좋다라고 생각할 것이다. 그러나 당신은 조사하고 싶어해도 좋다.

2

"파일을 읽을 때 문제가 있습니까?" 아무 문제 없습니다. POST 요청을 처리 할 때 파일에 대한 POST에 대한 MIME 첨부 파일이 있습니다. 이 파일을 읽는 것은 비교적 간단합니다.

"250MB 영역의 파일을 수락하는 데 문제가 있습니까?" 큰 파일을 전송하는 데 약간의 시간이 걸리는 것을 제외하고는.

"이 방법으로 파일을 받으면 파일이 메모리에 완전히로드됩니다."반드시 그렇지는 않습니다. 많은 웹 서버가 MIME 첨부 파일까지 요청을 처리하고 읽기를 중지하므로 HTTP 헤더, 요청 및 열린 소켓을 추가 처리에 사용할 수 있습니다. ASP에 대해서는 잘 모르지만, 거의 모든 프레임 워크가 데이터를 읽지 않는다는 것을 알고 있습니다. 프레임 워크는이를 응용 프로그램에 남겨 둡니다.

결과적으로 전체 내용을 메모리에 읽지 않고 청크로 읽고 해당 청크를 쓰거나 처리 할 수 ​​있습니다.

POST가 정확하게 수행되는 방법입니다. 좁은 HTTP 웹 서비스 영역을 벗어나지 않고도 대안이 많이 없습니다. 물론 FTP (TFTP, SFTP)와 같은 다른 프로토콜을 사용하여 파일을 이동할 수도 있지만 클라이언트 응용 프로그램을 작성하는 사람들에게는 혼란을 일으킬 수 있습니다.

원하는 경우 POST 메서드가있는 HttpWebRequest 개체와 첨부 파일이있는 스트림을 만드는 클라이언트 라이브러리를 제공 할 수 있습니다. 그러나 HttpWebRequest 클래스는 매우 단순 해 보이므로 많은 비용을 절약 할 수 있습니다. 다음은 code sample입니다.

+0

ASP.NET이 첨부 파일을 메모리로 읽는다고 확신하지만 의심 스러웠습니다. 테스트 해보아야합니다. 청크로 읽는 것은 내가 스트림을 수락하거나 웹 서비스 방식을 완전히 무시하고 입력 스트림을 직접 읽으면 가능하다. –

+0

들어오는 요청에서 스트림을 만들 수 있다고 생각합니다. 내가 찾은 코드 샘플은 기본적으로 보내는 요청에 스트림을 추가하는 방법을 보여줍니다. –

2

파일을 제출하기위한 간단한 POST 방법을 사용하면 파일 업로드를 관련 메타 데이터 (즉, 메소드와 번들 된 경우 메소드의 다른 매개 변수)에 연결하는 세부적인 사항 만이 잘못되었습니다.

오늘 저는 SOAP 호출에서 대형 객체를 처리하는 방법이 MTOM이라고 믿습니다. 이것은 최적화이지만 실제 페이로드에 대한 스트림 인터페이스를 제공합니다. 따라서 프레임 워크는 필요한 경우 큰 개체를 디스크에 쉽게 캐시 할 수 있습니다. 실제로 수행 할 수 있는지 여부는 다른 질문이지만 메모리에 250M 업로드를 흡수하지 않으려는 사람이 없어서 최신 첨부 파일이 큰 첨부 파일을 오프로드 할 것이라고 상상합니다. .

+0

나는 SOAP/MTOM/InputStream 방식이 우리의 서비스를 소비하는 주요 번거 로움이 될 것이므로 관리되지 않는 클라이언트를 두려워하게 될 것을 두려워하고 있습니다. –

+0

결국 SOAP은 XML 형식입니다. MTOM 형식은 간단해야합니다. MTOM 패킷을 "직접 작성"하더라도 서비스를 호출하는 단일 목적으로 유틸리티 기능을 만들 수 있습니다. 한 번 해보고 고객에게 제공해야합니다. 툴킷이 필요 없습니다. –