In our express (with typescript) app, we are calling an external api and normally we would send a http GET using axios like
foo/api/search/hello world where hello world is entered by the user of a web app. We call encodeURIComponent on the parameter so we will send foo/api/search/hello%20world to the external api. And this works fine until someone tried to enter something that is non-ascii, s.a. hello tânia; this causes us to send foo/api/search/hello%20t%C3%A2nia to the external api and we got a http 400 back.
Is this something that the external api should handle or we shall handle it on our side?
Either way, how to handle this?
So in general the encodeURIComponent() function encodes all special characters into their matching UTF-8 encoding, see here. So your client is doing everything right, but it seems like your server which is receiving the HTTP GET is for some reason not capable of correctly handling the UTF-8 encoded URI.
Related
I wanted to use vs code's extension REST client for testing purposes. So I used a curl of an existing API running on my local machine. But instead of JSON, I got HTML as a response. The curl works as expected in the terminal but not with the extension.
The same Behaviour is with another extension named Thunder Client.
Postman is getting JSON responses for the same API I believe that issue lies within vs code itself, I just don't know how to resolve it.
According to this article:
https://softwareengineering.stackexchange.com/questions/207835/is-it-ok-to-return-html-from-a-json-api
If you have declared you only accept one format in the header then the service should only send back that format or throw an error. If you have not put an ACCEPT in the header, the the service may send back whatever.
Check what is in the ACCEPT header:
But also check how Thunder Client translates the call in powershell:
I see that in my call the response is translated to JSON. I would guess that most REST clients are assuming that users want to work in JSON. Maybe that's what your two REST clients are doing?
this might be a stupid question but I was unable to find a solution, also no luck with search.
My Node-Red flow gets triggered by a HTTP Input because I want to create a REST Webservice. It works fine so far but I wonder how to verify the content someone send to me.
As I see right now, I can pass any kind of content. There is no verification if the content matches to the content I want as input.
If I set content-type to application/json, it only accepts json data. That's great but I also want to ensure, users can post only a specific json string.
If someone sends data I'm unable to proceed (not the json object I expected), I want to send HTTP 400 as response.
I'm pretty new to Node-Red and also to json. I'm more an old-school programmer using classic webservices and soap. What I'm missing is some kind of WSDL (not sure if it exists when using REST) and some kind of payload validation.
It would be great if someone can point me the way to go.
Best regards
Patrick
There are some nodes available for doing schema validation on JSON objects.
For example, node-red-contrib-json-schema-validator - which uses ajv as the validation engine under the covers. Unfortunately this node doesn't come with much in the way of help. Essentially it lets you provide your schema and if a message fails to validate, it logs an error which can be handled with a Catch node if you want.
I found the issue. It was too bad.
I just forgotten to set HTTP Header content-type to application/json.
node-red-contrib-json-schema-validator works like a charm if content type is set corret
I'm trying out chrome-extension advanced rest client app, but when I send something like:
http://myDom:34234/my/path/method?param=["{a-guid}"]
the actual parameter arrives on the server as "[\"{a-guid}\"]" how do I get it to send the array as an array rather than a string?
Proper URL for this request should looks like:
http://myDom:34234/my/path/method?param=%5B%22%7Ba-guid%7D%22%5D
All URLs must be encoded.
In the app you can expand URL panel and under "Query parameters" section encode values to proper form.
it depends on your server implementation (e.g. php, c#, rails, javascript, python, etc).
all headers arrive on the server as a string. it's up to the application to parse that string into a native object (e.g. an array) in that language.
in the php world, here's the code we use:
parse_str(file_get_contents('php://input'), $args);
update:
based on your comment below i suggest you use new JavaScriptSerializer.Deserialize(jsonString)
You need System.Web.Extensions dll for the same and import the following namespace.
Namespace: System.Web.Script.Serialization
for more info MSDN
We received a request to create a REST api. I was a little confused in the example of provided by our client. As you can see below, they've identified the app_id and secret in the URL before the #. The remainder of the URI looks like what I would expect.
Is this valid? I thought maybe this is some weird cURL format I haven't seen before.
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/
https://{application_id}:{api_secret}#api.example.com/entity/{entity_id}/entity_locations/{locations_id}/
Just seeing if anyone has seen this format before?
A URI is made up of various parts, one of them being the authority part, which can feature optional username:password element.
The full scheme is:
scheme://username:password#domain:port/path?query_string#fragment_id
This way your REST api remains stateless [not relying on previous app states like storing stuff in session]. But I advice you not to explicitly go with the username:password#stuff route, but to rely on Basic HTTP Auth, so the credentials are sent encoded in Base64 at least.
EDIT: a brief note about BasicAuth now you're asking - things go like this:
you make a request to http://johndoe:12345#service/api/foo/bar;
are credentials good? Ok, you get a 200 OK response with proper body;
are they not? You get a 401 Unauthorized response.
In the latter case, it's the browser [or any other program / script performing the request] that should prompt the user with the login popup.
Usually browsers ask you to cache credentials not to ask them every time, but this does not mean that they are not sent - it's just that every request to protected resources are featured with such header:
Authorization Basic base64encode(username:password)
Where base64encode is your custom way to encode the username:password string.
I need to call a web service from my classic ASP website. I have been provided with a URL and three variables from the SOAP provider:
URL of web service: http://www.theirwebsite.co.uk/B2bservice.asmx
Parameter1: CustId
Parameter2: PWord
Parameter3: OrderNo
So I'm supposed to send this SOAP request from my classic ASP website, along with the parameter values (which I've been given too) and it's supposed to return a string.
I've tested the SOAP response using soapclient.com, and sure enough if I enter the web service URL and add the paramter values, it returns a string, like it should.
The problem is I just can't find how to do it with classic ASP!! I've found numerous examples of calling a SOAP URL from classic ASP, but none of them mention how to pass parameters.
Can someone please show me a simple-as-possible implementation of how I get the return string from this web service in ASP, passing the parameters in?
Many thanks in advance for any help.
Dan, you have to change the GET for a POST
I don't know much about classic ASP and don't know if it has a SOAP client implementation, but if classic ASP allows you to send an HTTP POST with an arbitrary body and arbitrary HTTP headers, it should be possible to do what you want (in a somewhat hacky way).
Just issue a POST request with the entire SOAP message hard-coded except for your parameters. Make sure to get the Content-Type and SOAPAction headers right.
If you don't know how to properly create a valid SOAP message and to properly set the headers, use a tool like http://web.progress.com/en/actional/actional-diagnostics.html to send a test message, then use a tool like Fiddler to take a look at what was actually sent, and then hard-code it into your app.