We are wondering whether it is better to place parameters of a server method call within name/value pairs in s post, or post a JSON string to be processed by the server. The problem is that in some cases, the length of the parameters varies, and it is easier to handle this with a JSON. Also because we are trying to foresee the case in which our app users using these methods grows a lot and performance becomes an issue.
Which way do you think is the best choice? Is there any other suggestion?
Thank you all in advance!
Best way is to post a JSON. You can pass them in HTTP body and thereby give it some security and invisibility.
And JSON string can be even passed as a url parameter if u want.
Related
I am writing a rest client application and the way the server has been set up (beyond my control) is to perform specific filters the query string has a raw json attached as follows:
http://www.someurl.com/api/user?filter=[{"field1":"value1","field2":"value2","field3":"value3"}]
Currently I am using Robospice/Spring to handle the network requests and for regular queries (i.e. no json paramters) it works pretty well. However, whenever I try and process a GET request with the above described url, I keep receiving 500 server error. I tried the same request using This android-async-library, which seems to be able to handle the parameters a little better (200 OK etc). This has lead me to believe the issue is with the way the URL is formed/parsed.
My question is can Spring handle URLs of this format? or if anyone knows the best way to handle/encode it that will be usable for spring?
Yes possibly your url should be encoded especially when you post json in parameters(because of ", :, }, ' notations)
use this for creating your url
String url = Uri.parse("http://youradres.com")
.buildUpon()
.appendQueryParameter("filter", "[{\"field1\":\"value1\",\"field2\":\"value2\",\"field3\":\"value3\"}]")
.build().toString();
It is probably not a good idea. I would pass those values like this:
http://www.someurl.com/api/user?field1=value1&field2=value2&field3=value3
And manage those values on your controller. I think it is more rest-ish. However, going straight to your question. I think the problem is you need to "encode" your URL before you send those values. And then decode it back in your server.
I can not give you code because I don't use Java but this might help you to get on the right track.
I have an application which uses restful web services, the service returns a json object.
I wanted to know , what would be better , returning a json or xml response?
Please help as i am new to the concept.
The answer is that it doesn't really matter. They are both almost equivalent. They use slightly different API's so go with the one you feel more comfortable with.
Example of JSON parsing in Android you can find in this question.
Example of XML parsing in Android you can find in this question.
The only reason I can think of to use XML over JSON is when your webservice responses are huge. JSON usually requires the entire response to arrive before you can start parsing. XML easily supports a pull parser which can start parsing "on the fly" before all the data arrives - which can be much more efficient. But if your responses are small, you don't really need all that.
If your existing webservice already returns a JSON object, this could be reason enough to stick with JSON.
My client is an Android app and my service is an asp.net web api. I’m the only one using my service. I am trying to duplicate, in the Android-REST world what I am already doing in the Microsoft Windows Phone 7/ WCF SOAP world. I have numerous methods that both receive complex objects and return complex objects.
The WCF-SOAP world is simple. You can pass any complex arguments you want and return any complex results you want. Logically, it’s just a Remote Procedure Call.
But when I post questions about doing the same thing in REST, I’m told I should limit my services into GET, PUT, POST, and DELETE only. And that I should only do what is “proper” according to RFC2616. Some speak of this in almost a religious manner.
Forgeting about the religion, what’s wrong with using a GET for everything? Or what’s wrong with using a POST for everything? What I do does not fall into the simplistic RFC2616 categories. For instance I’m passing a thousand legs of a trip taken in a car and I’m getting back another version of that trip with erratic GPS errors smoothed out. Or, I’m sending a conversation in english and getting that conversation back in German.
In the android client I have the objects I want to send over HTTP already serialized into json strings by using Google-GSON. So my questions are…
How can I send these json strings to my REST Service as arguments in either GET or POST?
Is it possible and feasible to use just all GETs (or all POSTs) for all of my calls to my REST Service and how do I do that?
I have a more pragmatic question about this posted at sending a json string in a http url as I can’t find any examples anywhere of sending json strings over http GET or POST.
Thanks, Gary
Using the good HTTP verb is very usefull to simply know what to do when you request failed (for example) or just to do some specific stuff. If you sent a POST request, it's implicitly suppose that you have to parse your resource in order to obtain a stream which be sent via the request's body. In other hand, when you are retrieving data via GET, it's suppose that the request is gonna be sent back to you as a stream that you will mapped to your model, pojo, or anything else.
I can suggest you to use library such as RESTDroid. You can send POJO and receive POJO. It's a "resource oriented" library, so you can know at any moment if a particular local resource is remotely syncronized. Data persistence between local and remote is automatically handles.
RESTDroid is alpha released. You can have a look to RoboSpice. It's a powerful library to manage REST call but it's up to you to manage the persistency between local and remote resources.
1) The WCF-SOAP world is simple. You can pass any complex arguments you want and return any complex results you want. Logically, it’s just a Remote Procedure Call.
- IN REST:"You can pass any complex arguments you want and return any complex results you want too.
2a) Forgeting about the religion, what’s wrong with using a GET for everything?
In SOAP services WCF/or classical you are wrapping all requests into http POST so using single verb would end up to SOAP or - don't even think about it - your own communication protocol:-D
2b) You can technically compose GET request with non empty body - most of the servers ignore it by default though and it would be technically problematic to read it..
the other part of the question is answered by Pcriulan above
I'm building an Android client for a web service that accepts POST data. We're standing on the fence which format to choose for the POST data. According to me, the easiest way is to send it in UrlEncoded format but server side developer thinks JSON is better.
What are the pros and cons of using UrlEncoded / jsonEncoded / bsonEncoded format?
I would avoid xmlencoded data, but what about the others?
The answer to your question greatly depends on what kind of data you're going to send. If your data is mostly string values, numbers and the like, probably JSON would be your best solution.
Avoid url-encoded data, use MultiPart instead -- it takes a bit more work, but it's more secure (url-encoded data it's visible in the server logs) and you may send large files (images?) easily.
If you are sending maps (set of key-value pairs) and arrays, JSON is probably the easiest to work with from a developer standpoint on both client and server. If you need to optimize instead on use bandwidth usage for large set of non-media data, protobuf works well.
We're writing an app that communicates with an internet-based CMS in JSON. Unfortunately, some types of network connection e.g. through public Wifi have a web gateway that they require you to go through before you can use the net normally. This means we are trying to JSON parse an HTML webpage. I would expect it to throw an exception stating that the HTML isn't well-formed JSON but instead it tries to parse it, runs out of memory and collapses.
I have looked through the Android JSON functions and can't find a function that simply tells you if a string is JSON or not. Is there such a function? If not, am I simply going to have to write something heuristic to trap obviously non-JSON strings?
The exact way to check for its well-formed JSON is to create a JSONObject based on the string returned from HTTP Response. JSONException will occurs if the resulted string is not a well-formed JSON.
I don't know why you're running out of memory too soon. Is it because the returned string is very large? If so, you can take the advantages of the JSON format. Check the first character of the string. If it's { then it's probably JSON. Otherwise, it's not a JSON.
Please note the word "probably". It's because I don't know whether the server sometimes gives you another response with { as its first character and it's not a JSON. You decide.
You should read a JSON string formatted here.
You should be checking the Content-Type HTTP header of the response. If it is returning HTML, it will be text/html. If it is returning JSON, it will be application/json.
Telling you whether this is valid JSON or not would require complete parsing. Android bundles vanilla JSON parse working on like XML DOM parser - those parsers try to construct complete syntax tree in memory - thus they are prone to
low performance
heavy memory usage
I would suggest to use pull parser like GSON - there is also some kind of databinding which comes handy if you need objects out of your JSON or just strupped down binary ( 16KB ) to just parse ( I use it with my own databinding layer: https://github.com/ko5tik/jsonserializer )
Something like:
Header contentType = httpResponse.getFirstHeader("Content-Type");
if (contentType.getValue().compareToIgnoreCase("application/json") != 0) {
// response is not JSON
response = null;
}