I am using Savon 2.11.1 as a Ruby SOAP client.
Savon uses Nori to translate the SOAP response XML to a Hash. Nori supports the option convert_dashes_to_underscores which by default converts all dashes in SOAP response to underscores.
I tried to use this option in the client's constructor but I got the following error message
Savon::UnknownOptionError: Unknown global option: :convert_dashes_to_underscores.
Why is this option not supported for Savon? Any workaround?
Thanks
M
I don't know why it isn't supported. I guess because nobody needed it up until now. I propose you extend the code, create the unit tests, upload the sources to github and send a pull request to the main project. Simple as that.
You can also look into the documentation where you'll find that the following symbols are available to control conversion
:camelcase
:lower_camelcase
:upcase
:none
http://savonrb.com/version2/globals.html
Related
We have a requirement where we need to send .avro file as an input request to our API's. Really stuck at this point. If any detail example provided would be more appreciated.
Just use Java interop: https://github.com/intuit/karate#calling-java
You need to write a helper (start with a static method) to convert JSON to Avro and vice versa. I know teams using this for gRPC. Read this thread for tips: https://github.com/intuit/karate/issues/412
Also there is even a "karate-grpc" project: https://github.com/pecker-io/karate-grpc
Also see:
https://twitter.com/KarateDSL/status/1128170638223364097
https://twitter.com/KarateDSL/status/1417023536082812935
Just like how the response information can be accessed through response, responseHeaders etc, is there any way to access the request information? I noticed that request information is not available through variables. Are there are any workarounds to access this information?
I understand that we build the request ourselves in the test scenario using the Given, When steps, so it may sound redundant. The reason I'm looking for this is I would like to access the complete request details Karate would've built using our test definition. The idea is to make this information available to a java class which can be called through the Java Interop. More specifically, I'm trying to build a swagger request and response validator to be used from karate.
The workaround I am using is to explicitly create variables like apipath and apimethod and use them with path and method. This does the job, but still one has to ensure that these variables are explicitly set. It will be cleaner if whatever request Karate built is just accessible through a variable.
Please raise a feature request. We can look at making this available as karate.request or similar.
I'm using SoapUI to automate tests against my companies APIs. I've successfully setup and run dozens of these cases.
This tyme, I'm getting an error which, after exhaustive tracking down, I've found is due to our APIs requiring the "#" char itself rather than the URL friendly "%40" substitution.
The post request I want is structured like this:
https://<endpoint>.com/<resource>?<param>&email_address#example.com
And what I'm seeing made is:
https://<endpoint>.com/<resource>?<param>&email_address%40example.com
How can I enforce SoapUI to use the char itself?
I've tried setting headers, media type and representations (though possibly not through all permutations).
Thanks.
Use Disable Encoding for the parameter.
It is possible using multiple RAML files in one APIKit Mule Project?
Let's say I have two functions /api/func1 and /api/func2.
Each of the functions is defined in its own raml - func1.raml and func2.raml.
I've generated a flow in Anypoint for the first function using the APIKit wizard. It's working ok.
Now, I'm trying generating a flow for the second function. The flow is generated with no errors. However, it just doesn't work. I've tried fixing the URLs, bindings, configurations and nothing really helps.
Note, that I don't wanna bind both the RAMLs into one file. The reason is that it's easier to develop/maintain the functions separately.
The only solution I can see is to define two separate projects. But this is not really what I'd like to do.
So, looking for an advice of how to deal with this situation.
Thanks,
Ok, actually, it's possible.
What you need to do is make the "Path"es different in the HTTP connectors for the flows generated.
The apikit wizard generates the default path that looks like this: "/api/*".
So, Mule generates an error when attempting to deploy the app. What you need to do is changing paths to "/api/func1/" and "/api/func2/"
You can continue having a single RAML file and make external references to simplify your raml, here is an example:
#%RAML 0.8
title: Eventlog API
version: 1.0
baseUri: http://eventlog.example.org/{version}
schemas:
- eventJson: !include eventSchema.json
eventListJson: !include eventlistSchema.json
Also going by strict REST design it is recommended to have a resource related details maintained in a single RAML file.
Optionally you may edit the url's to resolve any context related conflict.
I'm designing an API to be as HTTP compliant as I can. This includes sending specific response codes back and using the Accept header to specify versions and response types.
I understand this may appear subjective, but I'm sure there's a conventional way of doing this. I have a set of response types that the API supports, along with a vendor-specific mime type to specify the type and version.
Currently, when the client specifies a non-existant version or type, I'm just returning a 400 Bad Request with an empty body, however, I want to return a useful error message. In the event that I don't know the response type, I feel a bit dirty responding with plain text (or defaulting to JSON). Is there a header I'm missing, or some convention that I should follow? I want to get this one right from the offset.
Thanks, and my best,
Jamie
Try the status code of 406 Not Acceptable.
http://support.microsoft.com/kb/943891/
This is a list of HTTP sub-codes supported by Microsoft IIS. I've found this page damn handy since it gives you some insight into the messages they use to handle various errors. There are some HTTP sub-codes that refer to headers.