As I have a requirement to build a rest service in Message broker to receive the multipart request from mobile apps and just passthrough the request to backoffice system to store the attachments in repository.
And back office system store the attachment and will send the http response to Message broker, then again message will passthrough the response back to mobile apps.
But the request message contentType= 'multipart/form-data' for attachment
and response message contentType= 'application/Json-data' for the status updates back to client system
So is it possible to have a different content type for request for 'multipart' and response 'json-data' for the rest http service?
Thanks.
As long as your REST service accepts and has a handler to process the multipart/form-data then it won't be a problem. Some services for example will ignore a request if it isn't in XML or JSON, others will accept various types of formats.
So check your REST service for what format it can process.
As for the response, again, if the client has a header stating it accepts JSON, then you can send it JSON. This is more easier to check as the REST service can check the "Accept" header on the request to determine if the client is happy to receive JSON.
Many REST services check this to send commonly either JSON or XML back.
So to summarise, yes you can mix and match request/response types as long as both the client and service are happy to accept and handle the request/response types.
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.
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.
I am have been setting up a WCF Client to connect to a Service that I do not have control of (I think the service is implemented in Java).
The service requires Certificate security and I got all the certificates setup but I get the following error when I connect to the endpoint
An HTTP Content-Type header is required for SOAP messaging and none was found.
I have setup SchemaValidationMessageInspector (http://msdn.microsoft.com/en-us/library/aa717047.aspx) to catch the Request and Response.
I can see that the Request is caught but not the response.
As I understand it is because the response is not of the SOAP format meaning that the Validation method is not triggered.
I expect that the real error is a 404, 403, 500 or something like that.
I have been using Wireshark to inspect the packets but it's all encrypted since it's too early in the "stack". I need the response right after the https decryption have occurred.
How can I catch the none SOAP responses so I can see the error in a clear format?
Use Fiddler or WCF Trace http://blogs.msdn.com/b/madhuponduru/archive/2006/05/18/601458.aspx to see the raw message. If you want to do this from code use a WCF custom messgae encoder http://msdn.microsoft.com/en-us/library/ms751486.aspx.
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?
I'm connecting to a webservice using WCF. I can authenticate on the server correctly, send my request, and get a signed response back.
The only thing is that the body of the response isn't encrypted. Ok, I'm fine with that. It's not my service and not my call how they do things, I'm just writing a client.
The issue is that WCF keeps giving me a MessageSecurityException stating that the'Body' required part of the response message wasn't encrypted. Where in my app.config can I specify that I couldn't give two flying craps that it isn't encrypted and it should be let through and read?
For the record, I'm using customBinding.
The protection level (which defaults to "EncryptAndSign" in WCF) is set on the service contract, e.g. your interface that defines the service methods:
[ServiceContract(Name="YourServiceContract",
Namespace="http://www.yourdomain.com/2009/09/WCF",
ProtectionLevel=ProtectionLevel.None)]
public interface IYourService
{
string SayHello(string inputString);
}
You can set it to "ProtectionLevel.EncryptAndSign" (which is the default), "Sign" or "None".
However, you cannot set it to be one thing for the request and another for the response - the protection level applies to both directions of your WCF communication.
Check out the Fundamentals of WCF Security which explains these topics (this one in particular on page 2).
Marc
There is a way to send a secured message and permit the response to be unsecured. However it requires a hotfix you need to request from Microsoft technical support. This has saved me when workign with a goverment service that required recured requests but send unsecured faults back. See here for more information on the hotfix.