API sends to my app message via http POST method.
To prevent data loss while my controller is off I want to use rabbit.
how to receive http POST requests in rabbitmq?
is possible at all?
No. There has to be some component which converts the requests. You also have to consider that the HTTP request requires a response. Do you respond with status 200/201 all the time, indicating "OK"/"Created"? What about errors you only discover later, when your controller is online again?
In your situation you might want to ask your users to send the data directly using RabbitMQ instead of using HTTP.
Related
If I were to send out a HTTP GET request to e.g. the Shodan REST streaming API, is this implemented on the server side by periodically sending out HTTP Keep-Alive messages to the client in case there is no new data to be sent out?
Or are there other options/techniques available for implementing REST streaming API endpoints?
There is no such thing as an http keepalive message.
The API you link to simply doesn't tell the client in advance how long the response body is, so a client can keep reading the newline-separated messages from what counts as one response until either side decides they're done.
I thought using RPC is bad practice but all the resources I am finding point to using RPC in order to get a response from a queue after publishing a request. Are there any other ways of doing it? Is it the best practice?
Thanks
MassTransit has built-in support for producing requests (which can be published, or sent directly to a specific endpoint). The request client can be created manually or added to a dependency injection container, and one or more response types can be handled.
MassTransit uses the bus endpoint to receive responses by default.
To register the request client in the container, the AddRequestClient method is used as shown below.
services.AddMassTransit(x =>
{
// configure transport/host/etc.
x.AddRequestClient<CheckOrderStatus>();
});
RPC is a common pattern, and producing requests when a response is required, it a regularly used approach. Another option is combining a command with an event, and observing the event separate from the request producer. However, if a linear programmatic flow is required, using RPC via the request client is an easy solution.
For my deployment I have a number of 3rd party systems that can only send HTTP POST requests with metrics (I need in the queue) and they cannot be re-configured. My goal is to have specific endpoints (or vhosts) that when POST'd to will automatically route to the correct queue, without needing the necessary routing key and other standard rabbitmq JSON data. As this modification is not possible in the 3rd party systems.
I can't find any way to do this natively as of now, but I believe it may be possible to configure a HTTP reverse proxy in the front, whereby any data sent to the specific endpoint, will be re-directed to the correct rabbitMQ HTTP endpoint, where I could then bolt in the nessary JSON data so it can be parsed by rabbitmq and placed in the realvent queue. I wanted to check if this is the only logical solution to this, or am I missing something obvious that can be done within rabbitmq's administration page or via config files.
First off I'm not too familiar with restlets , just starting out. I wanted to implement a broadcast chatroom where a client sending a message would have the message broadcast to all other clients.
My attempt was to use a resource on the server side where the client would send the message(as a String) using POST. The other clients would constantly have to poll this resource to receive the message. I know this method must be horribly ineffective.
I was wondering if there was a better method where a change on the server side(in this case the sending of the string message) would result in the server alerting the clients of this update.
Some things will come in version 2.1 with the new nio connector. Within web page, you might consider using technologies like Comet or HTML5 web sockets.
See the specification page from the developer wiki of Restlet: http://wiki.restlet.org/developers/172-restlet/g3/354-restlet.html
Thierry
I'm implementing a REST service using WCF which will be used to upload very large files. The HTTP headers in this request will communicate information which will be validated prior to allowing the upload to proceed (things like permissions, available disk space, etc). It's possible this validation will fail resulting in an error response. I'd like to do this validation prior to the client sending the body of the request, so it has a chance to detect failure before uploading potentially gigabytes of data.
RESTful web services use the HTTP 1.1 Expect: 100-continue in the request to implement this. For example Amazon S3's REST API can validate your key and ACLs in response to an object PUT operation, returning 100 Continue if all is well, indicating you may proceed to send your data.
I've rummaged around the WCF documentation and I just can't see a way to accomplish this without doing some pretty low-level hooking into the HTTP request processing pipeline. How would you suggest I solve this problem?