So I created a TCP\HTTP server (IN C#). I want to give to it namespace on my 80's port near to other HTTP servers I have. How to do such thing (step - by step)?
Look at HTTP Server Tasks in MSDN spec:
Initialize HTTP service API, call HttpInitialize
Register URLs with HTTP.SYS, call HttpAddUrlToUrlGroup
Receive a request, call HttpReceiveHttpRequest
Send a response, call HttpSendHttpResponse
Cleanup after urself, call HttpRemoveUrl and HttpTerminate
There is a also a fully fledged application sample at HTTP Server Sample Application.
As you can clearly see, HTTP.SYS API is a C API intended for C applications. You shouldn't be using it from C#, and I'd recommend against pInvoking the entire API. Managed applications have the alternative of using HTTP modules and extend the ASP.Net processing. This avenue will take care of many details needed in a managed server, like activation, hosting, process monitoring and recycling and so on and so forth.
The way you would normally interact with http.sys is by registering an ISAPI DLL with IIS. This is a good starting-point.
Related
I currently have a mobile application talks to a GraphQL API service which terminates SSL and then proxies requests to gRPC services. The gRPC services only talk to each other via gRPC.
This system works okay but writing all of the boilerplate to plumb the gRPC APIs through the GraphQL layer to the client is tedious and can be error prone.
I’ve started exploring the idea of talking directly to the backend via gRPC as the tooling has improved substantially over the last few years.
One issue I’m still wondering about, though, is the best way to disambiguate APIs only meant to be called internally by other services from those callable publicly by the native client.
There is also a third category, “hybrid” APIs where it can be called either internally or externally.
Examples —-
Internal: Sending an SMS via Twilio
Public: Log in to account
Hybrid: Update whether an inbox item is read (both from the app when opening a conversation and on the backend when a message is sent)
One option I thought of was an interceptor that passes along a context to indicate if the request is internal or public and use this in the code to return an error or perform additional validation on public requests.
Another option is creating an API service which is still gRPC but fulfills the same purpose as the GraphQL API service.
A third option is disambiguating public and internal services at an organizational level which might require duplicating some APIs that exist for both.
Are there other options I’m unaware of? How have you tackled this issue?
I have a system with microservice architecture. So I have a setup such that when I hit an URL, for example "http://localhost:8081/data/myId/" I get back a JSON response describing a resource. This is the system which I have created.
It turns out that there is some more complexity as to get this response, I am making a connection to an external service provider - this is what I want to use WireMock to mock, as this service provider has an API call limit. Let us say that I am interacting with this service provider at the following URL "https://api.dummyservice.com/". (So all "http://localhost:8081/data/myId/" calls consist of a "https://api.dummyservice.com/" call.)
So I am using WireMock as follows
java -jar '/home/user/Desktop/wiremock-standalone-2.19.0.jar'
--recd-mappings
--proxy-all https://api.dummyservice.com/
--verbose
--print-all-network-traffic
My intention is to listen to all calls at https://api.dummyservice.com/ through my microservice-based system so that I can stub and mock the responses. The problem is that I am not capturing any traffic at all when I access "http://localhost:8081/data/myId/" and get a successful response back!
Have I misunderstood WireMock's application? How can I debug this issue? It seems that I am performing quite a straightforward task.
I am on an Ubuntu 18.04 system if it makes any difference.
It seems you use standalone WireMock in a proper way, but please check correct params here
--record-mappings
--proxy-all="https://api.dummyservice.com/"
Firstly, here is state of my application:
I have a request coming in from a client (angularjs app) into my API (web api 2). This request is processed and a record is stored in a database. A response is then sent back to the client.
Currently, I have a windows service polling and processing this record(s).
Processing this record can be long running. As a side effect to processing this record, there might be notifications generated to be sent back to one or more clients.
My question is how do I architect this, such that I can utilise SignalR to be able to push the notifications back to the client.
My stumbling block:
I can register and store (in-memory backed by a db) the client's SignalR connectionid along with the application's own user identifier. This way I can match a generated notification with a signalr client.
At the moment, I'm hosting the SignalR hubs within the IIS process. So how do I get back from the Windows Service to IIS to notify the client when a notification is generated?
Furthermore, I should say I am already using SignalR elsewhere in the application and am using a SQL Server backplane.
The issue's with the current architecture:
Any processing is done in the same web request, and notifications are sent out via SignalR before a response to the client is returned. Luckily, the processing is minimal and very quick.
I think this is not very good in terms of performance or maintenance in the long run.
Potential solutions:
Remove SignalR hubs from IIS and host them somewhere else - windows service?
Expose an endpoint on the API to for the windows service to call to push the notification once a notification is generated?
Finally, to add more ingredients to the mix: Use a service bus to remove the polling component of the windows service, and move to a pub/sub architecture. Although this is more work than I want to chew off right now.
Any ideas/recommendations/constructive criticisms are welcome.
Thanks.
Take a look at this sample for starters
Another more advanced solution can be using a backplane to manage the communications between the front end and the backend...
HTH
I am query for a long time now.Where exactly we need to use WEB API and where should we use WCF restful services. What ever we want to achieve in WEB API we are able to achieve in WCF Rest. I tried to dig into answers but i got we need to do extra setting in wcf like URI templates,Contracts,endpoints. But its more on settings , but I wanted to known the real reason behind using WCF Restful Services.
Web Service
It is based on SOAP and returns data in XML format.
It supports only the HTTP protocol.
It is not open source but can be consumed by any client that understands XML.
It can be hosted only on IIS.
WCF
It is also based on SOAP and returns data in XML format.
It is the evolution of web services (ASMX) and support various protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ.
The main issue with WCF is its tedious and extensive configuration.
It is not open source but can be consumed by any client that understands XML.
It can be hosted with in the application or on IIS or using window service.
WCF REST
To use WCF as a WCF REST service you have to enable webHttpBindings.
It supports HTTP GET and POST verbs by [WebGet] and [WebInvoke] attributes respectively.
To enable other HTTP verbs you have to do some configuration in IIS to accept request of that particular verb on .svc files.
Passing data through parameters using a WebGet needs configuration. The UriTemplate must be specified.
It supports XML, JSON and ATOM data format.
Web API
This is the new framework for building HTTP services the easy and simple way.
Web API is open source an ideal platform for building RESTful services using the .NET Framework.
Unlike a WCF REST service, it use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
It also supports the MVC features such as routing, controllers, action results, filter, model binders, IOC container or dependency injection, unit testing that makes it more simple and robust.
It can be hosted within the application or on IIS.
It is a light weight architecture and good for devices which have limited bandwidth like smart phones.
Responses are formatted by Web API’s MediaTypeFormatter into JSON, XML or whatever format you want to add as a MediaTypeFormatter.
Choosing between WCF or Web API
Choose WCF when you want to create a service that should support special scenarios such as one way messaging, message queues, duplex communication etc.
Choose WCF when you want to create a service that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transport channels are unavailable.
Choose Web API when you want to create a resource-oriented services over HTTP that can use the full features of HTTP (like URIs, request/response headers, caching, versioning, various content formats).
Choose Web API when you want to expose your service to a broad range of clients including browsers, mobiles, iPhone and tablets.
For more details you can refer to http://www.c-sharpcorner.com/UploadFile/8a67c0/who-is-winner-web-api-or-wcf/.
Is there any way in spring where I can POST the requests to another domain from My controller? I have parameters which I need to pass in POST from the controller to another third party domain, is this possible?
What you probably want is for your server to act like a HTTP client and send some data via HTTP POST to a third server:
Your web app client ---> Your web server ---> Another web server
If that is indeed what you need, yes, it is possible. The fact that your application is a web server itself isn't important, although it can be confusing - it's easier to think about it as if you wanted to post the data from an ordinary command-line Java application.
One of the many tools that can help you is Apache HttpClient.