This topic contains 1 reply, has 2 voices, and was last updated by
November 5, 2018 at 5:39 pm #121953ParticipantPoints: 333Rank: Contributor
This is like an oxymoron. Anyone here ever worked with session-less API's? The basic premise, per the devs, the API uses a rolling session. Once you create a session it expires in 30 minutes, unless you make another call. Right now, I have the code creating a new session for every call, which is super inefficient (but it works flawlessly). Ideally, it would be nice to do a timed session, say 8 hours when you can leave the prompt come back after lunch and start running queries again rather than telling someone they need to re-create a session after 30 minutes of inactivity accessing the API.
The actual website appears to be doing a keep alive to persist a session. I was playing around by starting a background job where the session id and every 10 min just does a query to extend the time. As it session-less, there is no way on the back-end to get session information or see if it's been extended. Was just curious if anyone has dealt with basically persisting a session with with a session-less API.
Another option is keeping the PSCredential used to make the initial session and in the catch to attempt to do a reconnect for that error. Not sure that persisting the PSCredential in the module globally is a best practice as well.
November 5, 2018 at 6:44 pm #121966ParticipantPoints: 60Rank: Member
A keep-alive is just a header that is sent in an HTTP request.
Your best way I reckon to start is to have a look at the actual data being sent to and from the web server. Chrome is your friend here, specifically the Developer Tools option in the menu (unless you want to go hardcore and use something like Fiddler). This will show every request and response to and from the web server respectively. Look particularly at the headers and content, which contain all the juicy information. Using this methodology, you can replicate exactly how your web browser does its actions.
Just out of interest, have you tried using the invoke-webrequest with the -sessionvariable parameter and checked what you get returned in the variable? Is it null?
You must be logged in to reply to this topic.