I developed one application in Mulesoft for calling a SOAP webservice. While making GET call to a SOAP web service from Postman, query parameter value starting with # is not getting considered by my Mulesoft mapping.
e.g: http://localhost:8080/appName?queryParam1=#abc
In my mule application, the value for queryParam1 is coming as empty value. Could some one explain the technical reason for this. Is # is considered as escape character from Postman or Mulesoft Transform Message activity? Thanks in advance
I also faced the same issue in my API, in URI anywhere in between comes the '#' character the rest of your URI will go blank and the 404 HTTP error will occur.
I suggest you to get the value in query parameter without # character and later in the API code or flow prefix it. This will work.
Hope this will resolve your problem.
You will have to encode characters such as #. Refer this link for complete list of such characters. In your example:
Change: http://localhost:8080/appName?queryParam1=#abc
To: http://localhost:8080/appName?queryParam1=%23abc
Related
Is there any standard in HTTP regarding how request should be handled in case where an endpoint/request URL that supposed to not receive any query but the requester supply a query anyway ?
if it exist, what the standard states ? if not, is there any other related standard/statement regarding this like how request query supposed to be handled in general or such within the HTTP standard ?
thank you
By default, when you receive more parameters than expected and if you don't need it, you don't care
Is there any standard in HTTP regarding how request should be handled in case where an endpoint/request URL that supposed to not receive any query but the requester supply a query anyway ?
From the perspective of HTTP, the entire target-uri in the request line is the identifier for the resource:
POST /123?456
In this example, the target-uri is /123?456.
RFC 7231 defines 404 Not Found
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
Which is to say, if you want to draw the clients attention to the spelling of the target-uri, 404 Not Found is the way to do that.
That said, there are no "rules" about how the server interprets the target-uri. If you want to ignore the query part, and provide the same representation that is used for /123 then that's fine.
when you receive more parameters than expected and if you don't need it, you don't care
In messaging, ignoring unrecognized parts of the message can be useful when trying to ensure that your schema is forwards/backwards compatible; old clients using the old specification can talk to new servers using the new specification, and vice versa.
The same principle is described in the header specification for HTTP
Other recipients SHOULD ignore unrecognized header fields. These requirements allow HTTP's functionality to be enhanced without requiring prior update of deployed intermediaries.
I have one question about encoding diacritic chars in API request.
I can send via postman request GET /rest/city?query=Poznań, response is correct, in server logs city?query=Poznań is changed to city?query=Pozna%C5%84.
Also I have API test written in node.js (mocha, supertest) and here request GET /rest/city?query=Poznań return empty array, in server logs request method changed to GET /rest/city?query=PoznaD.
What's wrong with encoding in my API auto tests? Why ń changed to D?
Do You know how can I changed this to fix issue.
Also in logs city?query=Łódz changes in changes in city?query=Aódz
Ok, i have solution, just city?query=${encodeURI(Łódź)}
We have IBM cloud function API which accepts filename as a parameter. If I give filename which includes + or non english characters(chinese,japanese, etc) the api is returning 404 with message:"Error: Whoops. Verb not supported."
Please can you help me on this.
"Error: Whoops. Verb not supported."
This response from APIConnect when you consume the API implies Invoke action is not happening, that means input parameters are not as per expectation.
The backend of API Connect of every action in Assembly section is developed on JS and XSLT. Mainly for INVOKE action, it uses the concept of OpenURL to invoke the backend REST service.
From my understanding, JS will accept non-English and "+" operators but it will be part of the string - what I mean is this will not concat two strings.
Please try to drag "Gateway" action to the policy and execute the command
console.error("Input Req ::"+apim.getvariable('request.verb'));
Please share the response what you get in the DataPower gateway for this invoke.
I am using mocking service feature to build and test API design for one of the POC. I am getting HTTP error code 404, when posting message from design center through mocking service.
See the attached picture as well:
GET, PUT and POST request with without URI parameter are all working fine, but whenever I try to explicitly pass a specific gid or cid with the POST method it is showing the error from above.
I am attaching RAML file:
https://forums.mulesoft.com/storage/temp/6224-test.txt
I have read the documentation and have understood that we can pass any parameter value, when testing API with the mock service.
Could you please help me to find out, why the POST request with a specific gid or cid is returning an error code?
Based on the attached sceenshot you are trying to POST something to the root path of your API Mock Service.
Instead of deleting the parameters and sending the HTTP POST request to an URL like:
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/
Please try to keep the URI in the correct format:
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/groups/{gid}/channels/{cid}/chatthreads
In this URL you just have to replace the gid and cid parameters in the curly braces to the actual values.
Using your RAML file and a URI in the correct format, like the followine examples:
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/groups/10/channels/5/chatthreads
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/groups/10/teams
I am getting "204 No Content":
But when I remove the parameters and try to execute the HTTP POST on the wrong path, then I get "404 Not Found":
Based on the screenshot you have provided; the path to the resource was not complete in your HTTP request. This could have caused the HTTP error code "404 Not Found".
Please make sure that the full path to the resource is set in the API Console. This is needed to be able to identify what resource you want to POST (create).
For details about the usage of special characters (like '-' or '$') in the names of resources; please see the raml-js-parser. This parser is being used by the API Designer.
At the moment there are still open issues related to the handling of special charachters, like '-'. Please see the related bug report: Resource name is invalid: illegal character #129 in the github repository of raml-js-parser.
I would suggest to be using no special charachters in the resource names. (even though the current RFC standards eventually do allow the usage of '$')
According to this; the resource name "$ref" seems to be causing problems in your RAML. Please consider filing a bug report for the API designer in their github repository. However the issue could be caused by the parser as well...
I am writing a iOS client for a an existing product that uses a legacy SOAP webservice. I got the proper URL to send my SOAP/XML messages too and even have some samples. However, none of them seem to work...
I always get a 404 error with the following error text "Predicate mismatch for View"
I am using an ASIFormDataRequest for the actual request and apending the data (SOAP XML in this case) via [someFormRequest appenData:myData].
I am flat out of ideas here and am wondering what, if anything I am doing wrong. Or should I ping one of the back end guys? Could this error be a result of something on the server side?
This is an error message spit out by the pyramid web framework when attempting to access a URL without supplying all of the required parameters. You definitely want to double check that the URL you are using has all of the required params (headers, query string options, request body, etc) and if you're convinced that what you are sending is correct then but your backend guys because it's definitely a miscommunication or a bug between the two of you.