0

I'm implementing webserver logic using WatsonWebserver package. In request handler it might be needed to send another request to 3rd party webserver and handle a response from it. Sometimes 3rd party webserver can return bad request error with message that some parameters are missing. My webserver then send this response to the client. At this moment I want client to send me new request with missing parameters. Is it possible to communicate with client within same handler using existing HttpContextBase object in blocking mode?

using WatsonWebserver; using WatsonWebserver.Core; using Newtonsoft.Json.Linq; using System.Net; namespace GoogleAuthRequester { internal class Program { static void Main(string[] args) { WatsonWebserver.Core.WebserverSettings settings = new WatsonWebserver.Core.WebserverSettings("127.0.0.1", 9000, false); WatsonWebserver.Webserver server = new WatsonWebserver.Webserver(settings, DefaultRoute); server.Start(); Console.ReadLine(); } static async Task DefaultRoute(HttpContextBase ctx) { JObject json = JObject.Parse(ctx.Request.DataAsString); // some logic here // sending request to 3rd party HttpClient httpClient = new HttpClient(); using HttpRequestMessage request = new HttpRequestMessage(HttpMethod.Get, "https://3rdpartyservice/json/" + json); using HttpResponseMessage response = httpClient.Send(request); if(response.StatusCode == HttpStatusCode.BadRequest) { ctx.Response.StatusCode = 400; await ctx.Response.Send(response.Content.ReadAsStringAsync().GetAwaiter().GetResult()); } // Here I want to wait for a new request from the client with all needed parameters // Then send these parameters to 3rd party again } } } 

Is it possible to get new request in the same instance of the DefaultRoute task or should I handle it in another way by generating unique id for request (context) build my logic on top of this id?

5
  • @joelc could you please take a look here? Commented Mar 27, 2024 at 16:42
  • "Here I want to wait for a new request from the client with all needed parameters" - why? You report back that there is problem with request (i.e. BadRequest) and let client figure it out - i.e. send a new request with new data. Commented Mar 27, 2024 at 16:51
  • I'm forming some context in 'some logic here' code section. In order to not to form this context next time I'd like to ask client to provide needed params having needed context. My second option is to restore this context on next request, but I hope I can avoid this Commented Mar 27, 2024 at 16:54
  • Are you in control of the client or can define the contract? If yes - then persist the context (in memory or in database depending on the deployment specifics) and restore it on the next call (via some unique id send to client and then received back). Not sure that flow you want is even possible with HTTP. But you can look into utilizing websockets. Commented Mar 27, 2024 at 17:00
  • Client is developed by another team, but yes, we can agree the protocol. Also it is very good poing about websocket. I'll think about it Commented Mar 27, 2024 at 17:36

1 Answer 1

1

The route (in your case, the default route) isn't meant to be used in a way that keeps a persistent connection to the original caller. I would return the state back to the user (e.g. Bad Request, status 400) along with whatever information they need to execute the request correctly.

By trying to have a sort of state machine inside of a route, it would be in a way violating core principles of a RESTful architecture. Your response back to the caller upon identifying the failed request should give them the information they need to submit a new request that doesn't fail.

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.