When I drag an existing call to Autoresponder it generates a rule based on the method and URL. This works fine for REST APIs but not for APIs that are not based on the URL(like SOAP). Is there a way to make it respond based on the request body?
I'll explain the full use case. I have a .saz containing about 100 POST request to a SOAP API containing a repro for a bug in a application that I've created. I'm looking for an easy way to replay the communication that causes my app to crash.
You can use fiddler to respond with soap but because the URLs are the same for different calls, only one can be set up to respond at a time. After generating the rule create a .dat file that contains the soap response.
Related
I'm building a web app with Laravel for scheduling emails and when I was checking out the competitors, I noticed that one of them is using only one endpoint for all the requests and sending different payload in the POST request.
I thought of building my app's API the same way but I really don't find the use of this point.
I noticed that one of them is using only one endpoint for all the requests and sending different payload in the POST request.
It's a common approach to use when you want transport agnostic messaging. See, for example, SOAP.
We are successfully sending data for new, changed, and removed events to Google Calendar from a Scala app using Spray HTTP. However, we are currently sending one event per request, and this becomes very inefficient when there are multiple events for the current user. In these cases we would like to send batched data, as described here:
https://developers.google.com/google-apps/calendar/batch
The documentation begins with:
A batch request is a single standard HTTP request containing multiple
Google Calendar API calls, using the multipart/mixed content type.
Within that main HTTP request, each of the parts contains a nested
HTTP request.
Since we are already using spray http we would like to use its support for multipart/mixed requests (spray.http.MultipartContent) but it isn't clear that this is possible since the parts must consist of one or more spray.http.BodyPart instances and there doesn't seem to be a way to turn a spray.http.HttpRequest into a BodyPart.
Has anyone successfully done this? We are also taking a look at the Google API Client for Java but would rather not go down that path if there is a more Scala-friendly way to do it.
I have a BizTalk application where I have exposed schema as a RESTful web service, which calls another REST service. I am able to successfully handle GET, DELETE request.
Is there a way to handle POST request without writing a pipeline component to serialize the POST request to a schema?
Also, the application may have to handle several POST calls, so will it be possible to serve this from one single receive location and then filtering the request on the send port?
Please let me know if any more details are required.
So, here's the thing. You're mixing together some things that technically have nothing to do with each other.
For instance, a Plain Old Xml (POX) service, usually a POST, does not 'expose' a Schema in the way a SOAP service does. It just takes whatever content is POSTed to it.
Following that, serialization/deserialization is also a concept more related to SOAP that POX or REST.
So...
Yes, but what exactly are you doing?
Yes. A plain http endpoint can accept any content type. Once it's over the wire, all the normal BizTalk processing rules apply.
I'm trying to programmatically submit a form on a web site that I do not own. I'm trying to simulate what I would manually do with a web browser. I am issuing an HTTP POST request using an HTTP library.
For a reason that I don't know I am getting a different result (an error, a different response, ...) when I programmatically submit the form compared to a manual submission in a web browser.
How can that be and how can I find out what mistake I have made?
This question is intentionally language and library agnostic. I'm asking for the general procedure for debugging such issues.
All instances of this problem are equivalent. Here is how to resolve all of them:
The web site you are posting to cannot tell different clients apart. It cannot find out whether you are using a web browser or an HTTP library. Therefore, only what you send matters for the decision of the server on how to react.
If you observe different responses from the server this means that you are sending different requests.
A few important things that you probably have to send correctly:
URL
Verb (GET or POST)
Headers: Host, User-Agent, Content-Length
Cookies (the Cookie and Set-Cookie headers)
The request body
Use an HTTP sniffer like Fiddler to capture what you are programmatically sending and what your browser is sending. Compare the requests for differences. Eliminate the differences one by one to see which one caused the problem. You can drag an HTTP request into the Composer Window to be able to modify and reissue it.
It is impossible to still get a different result if you truly have eliminated all differences between the manual and the programmatic requests.
I mean that if I know the format of message that I want to send, then can I do it manually by sending the message as a string over HTTP without using gsoap and get the same desired result?
There is no problem doing it manually. It will even work using just telnet, as long as you use the correct headers and message body.
SOAP is an application layer protocol. So, it will make no difference if you use a tool
or just create and connect a Tcp/Ip socket to the web service endpoint. As long as you
put the right xml with the soap envelope, headers and body it will work well.