A folder's Files collection rejects a two-level $expand
$expand=ListItemAllFields/Editor — the obvious way to reach the editor through a file's list item — returns HTTP 400 on a folder's Files collection. Take the last editor and the author from the file itself — ModifiedBy and Author, one level deep.
$expand=ListItemAllFields/Editor – nejsnazší cesta k editorovi přes položku seznamu, která k souboru patří – vrátí na kolekci Files složky HTTP 400. Posledního editora a autora ber přímo ze souboru – ModifiedBy a Author, jedna úroveň.
Symptom
Listing a folder together with the name of whoever changed each file last:
GET /_api/web/GetFolderByServerRelativeUrl('/sites/projects/Shared Documents/Contracts')/Files
?$select=Name,TimeLastModified,ListItemAllFields/Editor/Title
&$expand=ListItemAllFields/Editoranswers
HTTP 400 – The $expand query is not valid for field 'Editor'Cause
On /items, the editor is one level away ($expand=Editor). Reached from a file through ListItemAllFields, it becomes a second level — and the Files collection rejects that.
Fix
The file carries its own user properties, one level deep:
GET …/Files?$select=Name,ServerRelativeUrl,TimeLastModified,ModifiedBy/Title&$expand=ModifiedByAuthor works the same way for the creator.
Notes
- To list one level of a library, use the folder API —
…/Foldersand…/Filesof that folder — rather thanitems?$filter=FileDirRef eq '…'. The filter runs over the whole list, so above the 5,000-item view threshold it gets throttled; the folder API asks about that one folder. Skip the system folders (Forms, names starting with_). - Moving what you listed?
movetoanswers with an empty body: Action endpoints return an empty body.