Wanted to create demo for how to leverage F12 tools to capture SharePoint Online REST api calls and replay into REST Postman. Allows adjustment of HTTP headers, inspecting output, and execute test API calls. Postman provides benefits of storing history, export data, and fine tuning the API headers.
Leveraging Chrome F12 enables us to quickly create a valid HTTP POST with correct authentication HTTP headers, cookies, and endpoint URL. Cheers.
Working with Gallery control in PowerApps can be a limiting way to navigate records. Many PowerApps include multiple screens with dedicated Gallery screens for navigation. Helping users locate records (sort, filter, scroll, and search) would be better accomplished with SharePoint Views. SharePoint List Views are more mature with full features for ad-hoc sort, filter, search and ability to save query (shared/personal) and provide hyperlinks to view ASPX pages.
Why not use SharePoint Views instead of Gallery control?
Turns out we can. On SharePoint modern pages:
Create new custom column with simple formula “=[ID]”
Apply JSON custom formatting to generate link <A HREF=”…power app URL..ID=1”> which opens PowerApps, giving ID number for a single record to Edit
Share View URL with end users to navigate records (sort/filter/search/paging)
This gives a robust and familiar navigation experience. Use PowerApps for it’s strength (input validation) and use SharePoint list for it’s strength (navigate records). Cheers.
Recently I came across the error message below when download a SharePoint 2013 List item REST api call to PowerShell. The cmdlet ConvertFrom-JSON does an excellent job. However, it is case sensitive with property names.
The resolution I found was to first string replace (case sensitive) to rename one of the source property names. Cheers!
Screenshot – Before
ConvertFrom-Json : Cannot convert the JSON string because a dictionary that was converted from the string contains the duplicated keys ‘Id’ and ‘ID’.
Watch the video below to see a demo of protecting WebAPI with HTTP header and a Client Secret. By default, new Web API projects lack any security mechanism and are open to any anonymous user. Protecting Dot Net methods with an IF() statement condition provides a simple security mechanism to ensure only users who know the Client Secret are able to run the API and execute the method.