0

I'm looking for a definitive answer on this. I was unable to find something definitive looking on my web.

  1. Is it strictly a no no to use the Session in a WebAPI REST service?

  2. Why does every example I see use Async/Await? (What is the advantage of this given each request already lives in its own thread?)

Thanks in advance!

Mr. B
  • 2,845
  • 1
  • 21
  • 31

2 Answers2

2

for 2:

What is the advantage of this given each request already lives in its own thread?

It is assumed that the WebApi call will somewhere down the line make another async call - for example database calls. In which case the Thread can be reused while waiting for the results.

Is it strictly a no no to use the Session in a WebAPI REST service?

Not sure about technically - but from a concept point of view, a REST service should not rely on sessions.

TomTom
  • 61,059
  • 10
  • 88
  • 148
  • Actually I would say is it MOST cases. Unless you have a very rare edge case, an API will actually at some point make an IO call. The edge cases where this is not needed can just be made non async. – TomTom Mar 30 '16 at 11:31
  • Okay so I can think of sending something off to a queue and reporting success, and making dependent IO calls at the same time and then combining them some how. That makes sense now. Thank you. There's not some other magic reason I was missing. – Mr. B Mar 30 '16 at 11:38
2

Is it strictly a no no to use the Session in a WebAPI REST service?

Not strictly forbidden, but generally discouraged. This is because session data can restrict your ability to scale out.

Why does every example I see use Async/Await? (What is the advantage of this given each request already lives in its own thread?)

It's all bout using fewer threads. While the request is (asynchronously) waiting, it won't use any thread. Thus, async/await enable you to scale less frequently. Async makes maximum use of your existing thread pool.

Stephen Cleary
  • 437,863
  • 77
  • 675
  • 810