This question already has answers here:
The argument type 'String' can't be assigned to the parameter type 'Uri'
(2 answers)
Closed 1 year ago.
I was trying to get information from an API endpoint by using:
Response response= await get('https://jsonplaceholder.typicode.com/todos/1');
but this didnt work so I had to parse it using Uri:
Response response= await get(Uri.parse('https://jsonplaceholder.typicode.com/todos/1'));
Why do we need to use Uri to parse the HTTP address?
Uri.parse method validates the provided URL.
If the provided URL is not valid, you see exception in console
Flutter team says:
If start and end are provided, they must specify a valid substring of
uri, and only the substring from start to end is parsed as a URI. If
the uri string is not valid as a URI or URI reference, a
FormatException is thrown.
You can learn more from here
Surely, Uri.parse method is most powerful than sending request to server before validation the URL
Related
I would like to know if there is a way to format special characters when parsing JSON requests from Flutter. I have tested a http request as such:
void curlRequest() async
{
String urlRequest = "http://my.web.url/webservice/rest/server.php?wstoken=my_token&moodlewsrestformat=json&wsfunction=core_user_create_users&users[0][username]=test_user_4&users[0][firstname]=John&users[0][lastname]=Doe&users[0][email]=john.doe#gmail.com&users[0][password]=Johns_Password";
http.post(urlRequest, headers: {'Content-type': 'application/json; charset=utf-8'}).then((response){
print("Response status: ${response.statusCode}");
print("Response body: ${response.body}");
});
}
I get the following response:
http://my.web.url/webservice/rest/server.php?wstoken=my_token&moodlewsrestformat=json&wsfunction=core_user_create_users&users%5B0%5D%5Busername%5D=test_user_4&users%5B0%5D%5Bfirstname%5D=John&users%5B0%5D%5Blastname%5D=Doe&users%5B0%5D%5Bemail%5D=john.doe#gmail.com&users%5B0%5D%5Bpassword%5D=Johns_Password&i=1
The request was invalid due to special characters being used. How do I make a request so that the special characters are also handled properly?
In a http restful request, the http GET request must be url encoded, which means that most special characters must be encoded in a way understandable by a webserver.
As such, characters such as the plus sign (+) or the question mark (?) must be replaced by their URL encoded equivalents (%2b for the plus sign and %3F for a question mark for instance) and vice versa for decoding.
Several URL encoders can be found online such as http://www.url-encode-decode.com/
In Dart you can use Uri.encodeFull() to encode string and Uri.encodeComponent() to encode a string component
Similarly to decode you can use Uri.decodeFull() and others
read more about this here Uri class
Switching to a better web hosting service resolved my issue. I was using AeonFree, which was a free web hosting service and had limited access for obvious reasons.
I also switched from the http package to using the dio package.
I have a restful api request like this:
http://0.0.0.0:4000/sentence=SUITS/Test。
And it gives an error in browser:
Not Found
The requested URL was not found on the server. If you entered the URL manually please check your spelling and try again.
Then I URL encoded the 'SUITS/Test。':
http://0.0.0.0:4000/sentence=SUITS%2FTest
This give the same error message.
If I remove the '/' from URL, and it works fine.
Why doesn't URL encoding work here?
This is python restful api with flask_restful.
If you provide "/" before Test it would consider "Test" as a resource and then in this case "sentence" should be considered as query param passed as GET payload after "?" like:
http://0.0.0.0:4000/Test?sentence=SUITS
I am passing a callback URL with a query string when sending an SMS message. I checked the debugger logs when the callback didn't seem to be working. I see "Error - 11200 HTTP retrieval failure" for the callback URL and it seems from the log details that the callback URL that I am passing is truncated after "?". The query string I am passing is not part of the URL and hence Twilio is getting the above error.
How to pass query string to Twilio's callback API?
We were actually having the same issue in our project. Looks like Twilio trims any query string parameters. Our workaround was to add any additional data to our route:
//original route:
GET /user/{userid}?myParam={myParam}
GET user/123?myParam=456
//modified route
GET /user/{userid}/{myParam}
GET user/123/456
However this means that you will need to update your server code to look for path parameters instead of query strings.
Hello i have GET method that URL example is:
http://localhost:8050/programs/b3cb6a0f-5d29-4744-a7e8-5fa0099dab18
Where the last String is just programId that I set as parameter in HTTP Request.
JMeter is kinda confused and the respond in raw request is:
GET http://localhost:8050/
GET data:
b3cb6a0f-5d29-4744-a7e8-5fa0099dab18
but there's just 404 in response data.
I can just delete parameter and write /programs/b3cb6a0f-5d29-4744-a7e8-5fa0099dab18 in path instead of /programs/ and everything works perfectly fine. IMO it's awful way. I'd prefer do it with parameter.
Write in path the parameter as /programs/${programId}.
This is part of the path and not parameter, parameters in GET request are different than POST see http methods
path/mypage?param1=value1¶m2=value2
Situation
I'm trying to create a REST API, where users can request responses in different formats.
For example, user can access:
example.com/oranges/1.xml (returns results in XML)
example.com/oranges/1.json (returns results in JSON)
Question
What's the proper HTTP response to indicate that a specific response format is not available?
For example, user tries to access:
example.com/oranges/1.yml (unsupported format)
Do I throw a 404 or is there a better response?
If you're encoding the desired format in the URL, then 404 is indeed the correct response -- it tells the client that it will never, barring server changes, be able to do anything with that URL.
With proper HTTP content negotiation, using the Accept request-header (which would be the more RESTamentalist choice), the appropriate response for an unsupported type would be 406.
I'd use 400. See e.g. http://en.wikipedia.org/wiki/List_of_HTTP_status_codes