Microsoft Graph allows downloading documents and conversion to PDF. This functionality works well for me when downloading it from OneDrive for Business, but when used with Groups, the format parameter is ignored and I just get original content (no conversion).
A request with URL constructed as /drive/root:/{path and filename}:/content?format=pdf works and the doc is converted to PDF before downloading.
A request with a URL constructed as /groups/{group-id}/drive/root:/{path and filename}:/content?format=pdf, however, ignores the conversion request.
I've tried with both /v1.0 and /beta endpoints.
Relevant API doc is Download the contents of a DriveItem and next topic for content conversion.
Related
In our project we started to use GRAPH API v.1.0 introduced some time ago and we wanted our users to be able to download *.eml file. For that we found that this is called MIME stream on MS side.
Long story short:
we use TypeScript (TS) and Graph Client library (#microsoft/microsoft-graph-client#^2.2.1);
We use request
await graphClient.api(/me/messages/${msgID}/$value).getStream()
The problem we started to notice is that 15MB email (with some attachments of 3-5MB) takes approximately 30sec to download whereas if email is downloaded via Outlook OWA (trhee dots on email > download) it takes few seconds.
Is there a way to increase the download speed using GRAPH api?
I tried to download MIME from graph and expected it to be as fast as downloading MIME from outlook web but it takes twice (maybe more) amount of time to download
EDITED:
As an example: downloading eml (13Mb) from https://outlook.live.com/mail
by uri like: https://attachment.outlook.live.net/owa/outlook_HEXNUM#outlook.com/service.svc/s/DownloadMessage?id=BASE64%3D&token=HUGETOKEN takes 2.5s
downloading eml using GraphApi by uri like:
client.api('/me/messages/${encodeURIComponent(this._fixId(mailId))}/$value').getStream() and reading stream takes 20-30s.
I would like to use multipart upload to allow uploading big files to the bucket split to chunks. Chunks should be uploaded in parallel, this the reason for use multipart upload (as far I know, resumable upload doesn't offer this feature).
https://cloud.google.com/storage/docs/multipart-uploads
The flow should looks in following way:
backend generates signedUrl for starting the upload
client calls previously generated url
backend generates signedUrl for uploading all the chunks
client uses previously generated url to upload multiple chunks
after all chunks are generated client confirms end of upload and chunks are merged to the file.
The problem I encountered, is following:
To perform PUT request to upload a chunk, two arguments needs to be provided: uploadId and partNumber. According to documentation, these arguments should be provided as query params. But signed url doesn't work if in the paths arguments differ from signature provided during generation. So for example, if i generate signed url with partNumber=1, I can't use it to upload chunk with partNumber=2. Is there any way to generate signed url with variable query params? Ideally something like https://.../uploadId=*&partNumber=*? Or the only option is to generate signed url for every chunk to match the signature?
Regards
I've checked the documentation, but didn't found anything useful. Unfortunately there is not much examples for multipart upload.
I followed this documentation to download the attachments of email.
Below is the API response.
If email attachment type is FileAttachment, I am able to get the file content in api response and able to save the attachment.
If email attachment type is ItemAttachment, I am not able to get the file content in api response. When I googled for it, I found this stack overflow question. I used the rest API mentioned in the answer. But it's giving itemAttachment content in html format. And if that ItemAttachment has any fileattachment in it, then I am unable to access it.
Is there any API available to download the itemAttachment as .eml file not as html?
Any suggestion/answers would be more than welcome.
I assume by .eml you mean you'd like to retrieve the email in MIME format?
Retrieving an email's raw MIME content isn't supported by Microsoft Graph API at this time. This has been a common request and there is an existing UserVoice request for it.
If this is a hard requirement for your scenario, you may want to take a look at Exchange Web Services (EWS). The Message object returned by EWS includes a MimeContent property.
This is now supported on https://outlook.office365.com/api/v2.0/me/messages/<Message-Id>/$value endpoint
I am using Microsoft Graph API for OneDrive (personal and business) integration. I am able to get content using the Search API but it is not returning the results expected per the documentation.
I have also compared response using Microsoft Graph Explorer with same request.
I am using these api requests:
GET /me/drive/search(q='doc') when searching on root.
GETÂ /me/drive/root:/{item-path}:/search(q='{search-text}') when searching on non-root folder
These calls are not returning all of the files I would expect. I am not able to files which are 0 byte (empty).
search not return specific type of files, like .png, .jpg,.md,.js, maybe even more. for my testing, it will return .pdf, docx, odp and xls
I'm experimenting with the Mendeley API to upload and retrieve documents and files and have a problem with the files/{file_id} endpoint.
I have a personal Mendeley account I'm using for testing, populated with some PDF documents.
For example, on the API documentation page if I call
GET /files
I see all the files I've added, but if I take an id value, then call
GET /files/{file_id}
using the ID, e.g.
https://api.mendeley.com:443/files/7b188de2-32a7-f067-51bd-520179e866b8
I get a strange response code of 0, response headers is {}, response body is 'no content'. This happens with all the ids from the file listing - is this a bug or am I doing something wrong?
If I alter the id string, I get a 404 Not found error, which is to be expected, so it's not an authorisation or other general issue.
It's a limitation of Swagger, the software that's used to run the API documentation web page.
That endpoint returns a redirect to an S3 download URL, to allow you to grab the file. Unfortunately Swagger doesn't handle the redirect properly, and it shows it as a response code of 0.
The endpoint is working correctly; it's just not displaying properly on the documentation page.