I have problem querying for "#microsoft.graph.downloadUrl" using microsoft graph endpoint.
Running a query like this:
https://graph.microsoft.com/v1.0/me/drive/root/children?$select=id,name,file,folder,size,lastModifiedDateTime,#microsoft.graph.downloadUrl
Returns a bad request error with message: "Syntax error: character '#' is not valid at position..." I had not such a problem with OneDrive direct endpoint so I am wondering how exactly should I run the intended query?
Earlier this year the attribute #content.downloadUrl was renamed to #microsoft.graph.downloadUrl.It looks like there is an issue/discrepancy between the attribute's name in the results verse the query parameters.
The $select clause is still looking for the original name. As best I can tell, this isn't documented at the moment. That said, this query should do the trick for you:
/me/drive/root/children?$select=id,name,file,folder,size,lastModifiedDateTime,content.downloadUrl
Related
Is there a way to specify that I only want to return the first record (or last) of a expanded set of child records using odata?
http://myurl/odata/ParenTable?$count=true&$filter=(Id eq 123456)&$expand=ChildTable($orderby=AddedTimeStamp desc;$top=1)
This is what I am attempting but it returns the message
The query specified in the URI is not valid
Your URL convention is compliant to OData v4 for the behaviour you are expecting.
11.2.4.2.1 Expand Options
The set of expanded entities can be further refined through the application of expand options, expressed as a semicolon-separated list of system query options, enclosed in parentheses.
Allowed system query options are $filter, $select, $orderby, $skip, $top, $count, $search, $expand, and $levels.
But there are older versions and proprietary implementations that are known to not support all or in some cases any of these options like filtering or limiting ($skip,$top) expressions within the $expand query option.
.Net implementations do not support $search OOTB, the API author must manually implement the query option.
That specific error is generally an indicator that the path component, not the query is invalid as most OData runtimes will return more descriptive error response when the resource or collection was correctly resolved but the query could not be parsed or executed. In this case I suspect you have anonymized the path, so we can only speculate, for instance there is an obvious potential typo in the documented path,
there is a 't' missing have you tried:
http://myurl/odata/ParentTable?$count=true&$filter=(Id eq 123456)&$expand=ChildTable($orderby=AddedTimeStamp desc;$top=1)
or is the resource pluralised:
http://myurl/odata/ParenTables?$count=true&$filter=(Id eq 123456)&$expand=ChildTable($orderby=AddedTimeStamp desc;$top=1)
http://myurl/odata/ParentTables?$count=true&$filter=(Id eq 123456)&$expand=ChildTable($orderby=AddedTimeStamp desc;$top=1)
You should include an example of the URL that does work, try without the $top and without the $orderby clauses within the expansion clause. We need to eliminate the errors related to a bad path, vs a bad query.
If you do this via Postman, you can then update your question and post the entire response content.
Both the current ASP.Net and ASP.Net Core implementations do support this, if you are the author of the API please include your controller implementation and the version of the framework you are using so we can assist in greater detail.
An Alternative
If your API does not support this, then given that you are limiting to the $top=1 you could invert the request and use the Child collection resource instead:
Assuming that ~/ChildTable is the route to the ChildTable referred to in your example expansion
http://myurl/odata/ChildTable?$filter=ParentTable/Id eq 123456&$orderby=AddedTimeStamp desc&$top=1&$expand=ParentTable
While trying to access the above odatav4 link with $apply query it shows an error as
"The query parameter '$apply' begins with a system-reserved '$' character but is not recognized."
but works if (apply) used instead of ("$apply")
https://services.odata.org/V4/Northwind/Northwind.svc/Products/?$apply=groupby((UnitsInStock))&$count=true&$top=1000
service link
I can't find the reason why the $apply is not working, since it was working previously
That service is an older implementation of WCF Services that is only partially compliant with OData v4 query syntax and as such does not support $apply.
but works if (apply) used instead of ("$apply")
You will notice that although there is no error, the query is returning the same results as if you had not included the $apply query option at all.
Your query syntax should work on a properly compliant API though, for instance you can use the TripPin service:
this query itself is not very useful, but it demonstrates the syntax
https://services.odata.org/TripPinRESTierService/People?$apply=groupby((LastName))
We have encountered an odd issue (inconsistency) which seems to be related to the $filter capability of the fetch messages endpoint on Graph.
We reply on querying for messages by their internetMessageId field.
This normally works, but in some cases we’ve seen that the result set is empty (no error), and the odd thing is the same message can be fetched by its subject or sender’s address.
This API call returns an empty result:
https://graph.microsoft.com/v1.0/users/<user_principal_name>/messages?$filter=internetMessageId eq '<CAPJZXvF23=Ut7ksuJzCV+dQa6Pjy+3+uRU7j0v-GLydAi974Rg#mail.gmail.com>'
This API call works:
https://graph.microsoft.com/v1.0/users/<user_principal_name>/messages?$filter=sender/emailAddress/address eq '<sender_address>'
We looked into this, and the problem here is with the app behavior, not the service.
Both queries work as expected, provided that the URL query parameters are correctly encoded by the app, per HTTP encoding practices.
In the first request, there are + characters in the internetMessageId value that the app does not encode before sending the request; the service decodes them into spaces, and that is why the query returns empty results.
When the query string is properly, the correct results are returned, as expected.
We recommend apps always encode the request URL.
The following URI triggered an error in the public OData service:
http://services.odata.org/V4/Northwind/Northwind.svc/Suppliers?$filter=Address eq '<A'
Entity type Supplier contains property Address of type Edm.String. So, the value of Address may contain any UTF-8 character from the definition (see section 6. Primitive data types).
The server responds with:
Runtime Error: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons).
Is the there something wrong with this URI or it is really a problem on the server side (e.g. inappropriate parsing of the $filter query option)?
You should encode your query URL, e.g. with help of
http://prasannaadavi.com/2014/06/handling-special-characters-in-odata-queries.html
How are special characters handled in an oData query?
In your special case you should try encoding "<A" with "<A"
--> found in https://web.archive.org/web/20150101222238/http://msdn.microsoft.com/en-us/library/aa226544(SQL.80).aspx)
I'm attempting to retrieve the "shares" graph data for a number of pages in JSON format. I suspect that the errors I am encountering stem from the fact that some of the URLs have commas in them, and are being parsed as an attempt to pass multiple ids.
Returns graph data.
https://graph.facebook.com/?ids=http://celebritybabies.people.com/2012/08/23/backstreet-boys-howie-dorough-expecting-second-son/
Returns error 2500 "Cannot specify an empty identifier"
https://graph.facebook.com/?ids=http://www.people.com/people/article/0,,20624518,00.html
Encode the commas, still returns 2500
https://graph.facebook.com/?ids=http://www.people.com.people.article/0%2C%2C20624518%2C00.html
There doesn't seem to a way around it other than to use the normal inspection
http://graph.facebook.com/http://www.people.com/people/article/0,,20624518,00.html
You may have to file a bug at http://developers.facebook.com/bugs though I feel as the answer would most likely be "Status by design".
You could try using FQL instead, querying the link_stat table:
SELECT url, normalized_url, share_count, comments_fbid FROM link_stat
WHERE url = 'http://www.people.com/people/article/0,,20624518,00.html'
(See result in Graph API Explorer.) You can also use WHERE url IN ("…", "…", …) to check multiple URLs at once.
This also returns a comments_fbid of 10151022112466453, and that one you can look up via the API, https://graph.facebook.com/10151022112466453
Maybe this can work as a workaround, until Facebook fixes this problem.