Call ServiceStack service from Powershell

Maybe this is the wrong place to ask, but maybe somebody has successfully done this.

I try to call a REST API of one of my servers using Powershell. The call gets correctly processed on the server but I cannot see the results, e.g. the ResponseDTO. This is my PS script:

$request = @{
     PlatformId = 3308668551
     BizBusApplicationIntegrationKey = "TopalAccounting-728270854"
     ActivatingUserName = "Joe Doeeeee"

$Url = ""
(Invoke-RestMethod -Method Post -Uri $Url -Body $request).model

The challenge is the last line. If I simply call Invoke-RestMethod -Method Post -Uri $Url -Body $request it retuns a html page with about 10000 characters. Inside this page I can find my response object as JavaScript…

Does anybody know how I get the output correctly as JSON object??

For those who are interested: I got it working with a Bash script. Instead of curl (I consider it as very user-unfriendly…), I use a tool called httpie which makes calling REST services from Linux command line or bash scripts extremely easy! Here my bash code: (replace --verbose with --body to just get the response DTO as JSON data, --verbose is good for debugging only!)

http --verbose POST $url \
     PlatformId=3308668551 \
     BizBusApplicationIntegrationKey=TopalAccounting-728270854 \
     ActivatingUserName=='Joe Doe'

And the result (just test data, don’t waste your time trying keys and passwords… :stuck_out_tongue:)

POST /bbopman/platform/confirmtopalserverregistration?ActivatingUserName=Joe+Doe HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 92
Content-Type: application/json
User-Agent: HTTPie/0.9.4

     "BizBusApplicationIntegrationKey": "TopalAccounting-728270854", 
     "PlatformId": "3308668551"

 HTTP/1.1 200 OK
 Content-Type: application/json; charset=utf-8
 Date: Wed, 20 Jun 2018 19:53:05 GMT
 Server: Kestrel
 Set-Cookie: ss-id=WcEVPk9s7NoQWvwOn9Zf; path=/; samesite=lax; httponly
 Set-Cookie: ss-pid=xMJ5iGNv1ulIPgwHmtWh; expires=Sun, 20 Jun 2038 19:53:06 GMT; path=/; samesite=lax; httponly
Transfer-Encoding: chunked
Vary: Accept
X-Powered-By: ServiceStack/5.02 NETStandard/.NET

     "applicationIntegrationKey": "TopalAccounting-728270854", 
    "applicationName": "TopalAccounting", 
    "bizBusApiKey": "sYN9JgZMEzObtRTZ3-HPjwcoJSVpz_9u", 
    "platformId": 3308668551, 
    "platformName": "testmüller", 
    "rabbitMqPassword": "dTYiVeZpyaMe", 
    "rabbitMqUserName": "TopalAccounting-3308668551", 
    "rabbitMqVhost": "topacc"

If anybody could give me a hint regarding the Powershell version I would greatly apreciate!

You’re best posting on StackOverflow with the #powershell tag as you’re after devs with PowerShell experience who’ve called HTTP URLs, the fact it’s calling a SericeStack HTTP Service is irrelevant here.

@tbednarz If you’re getting html output, you probably need to add a accept header for json, or do it the lazy way and add .json to the end of url. The Invoke-RestMethod isn’t going to supply the accept header for you, even though it’s expecting JSON output.

Wow! Adding .json to the end of the URL did the trick. It returns the expected response DTO! Thanks a lot, Powershell is kind of magic as always…

That’s no powershell magic, that’s ServiceStack inferring the Content Type from the format extension of your custom Route.

Even better, there are reasons, why I use ServiceStack and renew it every year… A very smart library is one and the excellent support is another one…

I just wonder why the PS script needs

$Url = "" to return JSON while httpie under Linux is happy with

url="" to return JSON.

Probably httpie is setting some headers behind the scenes, at least the docs say that it assumes JSON as the default content type, otherwise you have to set it explicitly. Maybe I should have a look with Fiddler, on Linux it seems to offer a Beta…

There are multiple ways to specify the Content-Type for a Request:

To override the Content-type in your clients, use the HTTP Accept Header, append the .json suffix or ?format=json

Your HTTP Client is likely setting the Accept HTTP Request header.