Add PipeName parameter to Invoke-RestMethod and Invoke-WebRequest docs

[mdaneri]

Document -PipeName parameter for Invoke-RestMethod / Invoke-WebRequest (PowerShell 7.6)

PR Summary

Documents the new -PipeName parameter for both Invoke-RestMethod and Invoke-WebRequest in PowerShell 7.6.
This parameter enables sending HTTP requests over a local Windows named pipe transport.
It supports scenarios where an HTTP-speaking service is exposed only via a named pipe rather than a TCP port.

Key points:

• Added parameter help section for -PipeName in both cmdlet help files.
• Added a new usage example to each cmdlet (Example 10 for Invoke-RestMethod, Example 12 for Invoke-WebRequest).
• Clarifies that -PipeName is Windows-only, local-only, and mutually exclusive with -UnixSocket.
• Notes version availability (introduced in PowerShell 7.6).
• Mirrors style and structure used for existing -UnixSocket parameter documentation.

Related feature implementation PR:

• Add -PipeName Support to Web Cmdlets PowerShell/PowerShell#26024

(No functional engine changes are included in this PR—documentation only.)

Additional Details / Rationale

Some self-hosted or system components expose lightweight HTTP endpoints over named pipes instead of binding to a TCP socket (for isolation or reduced surface).
Documenting -PipeName improves discoverability and provides parity with the previously documented -UnixSocket parameter.

Changes Included

• Update: Invoke-RestMethod.md – new -PipeName parameter section + example.
• Update: Invoke-WebRequest.md – new -PipeName parameter section + example.
• Consistent wording: local-only, mutually exclusive with -UnixSocket, version note.

Usage Snippets

# Invoke-RestMethod over a local named pipe
Invoke-RestMethod -Uri 'http://localhost/status' -PipeName 'MyLocalHttpPipe'

# Invoke-WebRequest over a local named pipe
Invoke-WebRequest -Uri 'http://localhost/api/info' -PipeName 'ServiceControlPipe'

Compatibility / Limitations

• Supported only on Windows (named pipes are a Windows-specific transport in this context).
• Local machine only; does not support remote pipe endpoints.
• Mutually exclusive with -UnixSocket.

Related Work / Follow Ups (Optional)

• (Optional) Add CHANGELOG entry for 7.6 if not already covered by feature PR.
• (Optional) Add cross-links in conceptual docs for advanced transports.

PR Checklist

• Descriptive Title: Title summarizes the documentation change.
• Summary: This PR's summary describes scope and intent.
• Contributor's Guide: I have read the contributor's guide.
• Style: Adheres to the style guide.

[learn-build-service-prod]

PoliCheck Scan Report

The following report lists PoliCheck issues in PR files. Before you merge the PR, you must fix all severity-1 issues. Other issues are also a high priority. The AI Review Details column lists suggestions for either removing or replacing the terms. If you find a false positive result, mention it in a PR comment and include this text: #policheck-false-positive. This feedback helps reduce false positives in future scans.

✅ No issues found

More information about PoliCheck

Information: PoliCheck | Severity Guidance | Term
For any questions: Try searching the learn.microsoft.com contributor guides or post your question in the Learn support channel.

[github-actions]

Expectations

Thanks for your submission! Here's a quick note to provide you with some context for what to expect from the docs team and the process now that you've submitted a PR. Even if you've contributed to this repo before, we strongly suggest reading this information; it might have changed since you last read it.

To see our process for reviewing PRs, please read our editor's checklist and process for managing pull requests in particular. Below is a brief, high-level summary of what to expect, but our contributor guide has expanded details.

The docs team begins to review your PR if you request them to or if your PR meets these conditions:

• It is not a draft PR.
• It does not have a WIP prefix in the title.
• It passes validation and build steps.
• It does not have any merge conflicts.
• You have checked every box in the PR Checklist, indicating you have completed all required steps and marked your PR as Ready to Merge.

You can always request a review at any stage in your authoring process, the docs team is here to help! You do not need to submit a fully polished and finished draft; the docs team can help you get content ready for merge.

While reviewing your PR, the docs team may make suggestions, write comments, and ask questions. When all requirements are satisfied, the docs team marks your PR as Approved and merges it. Once your PR is merged, it is included the next time the documentation is published. For this project, the documentation is published daily at 3 p.m. Pacific Standard Time (PST).

[learn-build-service-prod]

Learn Build status updates of commit 8c77a4b:

✅ Validation status: passed

File	Status	Preview URL	Details
reference/7.6/Microsoft.PowerShell.Utility/Invoke-RestMethod.md	✅Succeeded	View (powershell-7.6)
reference/7.6/Microsoft.PowerShell.Utility/Invoke-WebRequest.md	✅Succeeded	View (powershell-7.6)

For more details, please refer to the build report.