PnP Powershell has this nice wrapper function around the SharePoint api, Invoke-PnPSPRestMethod.
Would it be nice if we had that too in the CLI? For example for the SharePoint and Graph API's.
Why would a user use that?
- It is useful if you have specific wishes around (for example) data retrieval. The user might be able to optimize scripts by just running one command instead of a few.
- It is useful if there's some functionality not (yet) covered in the CLI.
Why would we add it?
Currently you would need to get a token using m365 util accesstoken get and construct the call using a tool like curl or Invoke-WebRequest. That works fine, but it would also be nice if we take away at least some of the plumbing for the user. This means less code to write for the user. An still a lot of flexibility.
We might also be able to add extra's like retrieving all items (aka fix paging for the user)
It's a more advanced scenario for more advanced users. But I believe it could add a lot of value.
Any ideas/opinions on this?
Specs below
request
Invoke a custom request at a Microsoft 365 API.
Usage
Options
| Options |
Description |
-u, --url <url> |
The request URL. |
-m, --method [method] |
The HTTP request method. Accepted values: get, post, put, patch, delete, head, options. The default value is get. |
-r, --resource [resource] |
The resource url for which the CLI should acquire a token from AAD in order to access the service. The token will be placed in the Authorization header. By default, the CLI can figure this out based on the --url argument. |
-b, --body [body] |
The request body. |
-a, --accept [accept] |
A convenience option to set the accept header of the request. |
Remarks
This command will send a raw request to the targeted API. It will not make any assumptions on the type of content that's sent or returned.
It does set the Accept header to application/json by default.
Additional headers can be specified as unknown options, eg: --content-type 'application/json'
Examples
Call the SharePoint Rest API using a GET request with a constructed URL containing expands, filters and selects.
m365 request --url "http://contoso.sharepoint.com/sites/project-x/_api/web/siteusers?$filter=IsShareByEmailGuestUser eq true&$expand=Groups&$select=Title,LoginName,Email,Groups/LoginName" --accept "application/json"
Call the Microsoft Graph beta endpoint using a GET request.
m365 request --url "https://graph.microsoft.com/beta/me"
Call the SharePoint API to retrieve a form digest.
m365 request --method post --url "http://contoso.sharepoint.com/sites/project-x/_api/contextinfo" --accept "application/json"
Call the SharePoint API to update a site title.
m365 request --method post --url "http://contoso.sharepoint.com/sites/project-x/_api/web" --x-requestdigest "somedigest" --x-http-method "PATCH" --body '{ "Title": "New title" }' --content-type "application/json"
PnP Powershell has this nice wrapper function around the SharePoint api, Invoke-PnPSPRestMethod.
Would it be nice if we had that too in the CLI? For example for the SharePoint and Graph API's.
Why would a user use that?
Why would we add it?
Currently you would need to get a token using
m365 util accesstoken getand construct the call using a tool like curl or Invoke-WebRequest. That works fine, but it would also be nice if we take away at least some of the plumbing for the user. This means less code to write for the user. An still a lot of flexibility.We might also be able to add extra's like retrieving all items (aka fix paging for the user)
It's a more advanced scenario for more advanced users. But I believe it could add a lot of value.
Any ideas/opinions on this?
Specs below
request
Invoke a custom request at a Microsoft 365 API.
Usage
Options
-u, --url <url>-m, --method [method]get, post, put, patch, delete, head, options. The default value isget.-r, --resource [resource]--urlargument.-b, --body [body]-a, --accept [accept]Remarks
This command will send a raw request to the targeted API. It will not make any assumptions on the type of content that's sent or returned.
It does set the Accept header to
application/jsonby default.Additional headers can be specified as unknown options, eg:
--content-type 'application/json'Examples
Call the SharePoint Rest API using a GET request with a constructed URL containing expands, filters and selects.
Call the Microsoft Graph beta endpoint using a GET request.
m365 request --url "https://graph.microsoft.com/beta/me"Call the SharePoint API to retrieve a form digest.
Call the SharePoint API to update a site title.