My company has a Phonegap application that's running into errors with UIWebView; it's hitting the 10MB memory cap. We're using .NET MVC4 as our backend.
This is due to a very large JSON response from a sync call. The JSON string (approximately 12 megs of data) is saved to memory, which causes a memory exception. Due to the way our application works, we have to send this data.
I'm considering using Oboe.JS to stream in the JSON response (to avoid the allocation of the full JSON object). I think that this may fix the issue on the frontend, but I'd like to stream the JSON response from the backend. I know that there are chunking methods, but I'd prefer not to use that option.
Currently, our controller method produces an object, serializes it to JSON, and sends the entire response. I would like to open a one-way HTTP stream, if possible, and asynchronously write JSON data to this stream (which Oboe would parse on the client side).
Are there any technologies that fit my use case, or can someone point me to some methods I may use to accomplish this? I don't need a two-way conduit - I just want to write the JSON to the HTTPstream as objects are produced.
Thank you.
Related
I have a web api based server. All controller methods accept objects and return objects (parsed from/to json by the framework). This has been working fine.
However, due to a new requirement, I need to create an adapter and place it between clients and the server. The adapter will be responsible for translation of a small subset of client messages before passing them to the server.
I'd like to avoid unnecessary deserialization/serialization from/to json of messages that do not need to be translated. That is, in majority of cases I'd like to pass raw json client requests to the server and raw json server replies to clients.
The controller methods that will do the translation will have 'standard' signatures - no problem here. However, I'm not sure how to forward messages (json strings) from clients to the server (and vice versa) without deserialization and serialization.
Is this possible in ApiController?
Thanks.
I have zero experience with Web API and JSON. My requirements are to create a service (I'm using Web API for this) that will accept MIME Encoded JSON data. The service will take that data, insert it into a database, and return the primary key value back to the client.
My hang-up is being able to know where to even start with this. A couple of questions that I have are:
When the device sends the JSON data, how will the service "accept" it? Meaning, what's being passed to the service isn't an URL that we commonly see with MVC (/Controller/Action/ID) which then invokes the Action Method. So, how will the service know what to invoke if I'm passing raw JSON data?
How would I test this if I don't have a device that sends the JSON data yet? Would I manually invoke an AJAX call and call that particular action method and pass in the JSON data that way?
I apologize for the seemingly elementary questions.
Thanks.
When you call a WebAPI-method you still have to specify the endpoint:
Example:
PUT /api/people
MVC knows from that that it should call the put-method on the PeopleController.
You can send raw JSON-data to test it. A good tool for that is HttpFiddler: http://fiddler2.com/
As for where to start, try to create a basic WebAPI-project with visual studio, it will include some samples and you can get going from that. If you run into wall, you can come back here
I am trying to access a web service, via an AFHTTPClient subclass, that has a complication
If the request succeeds, the content is returned as JSON. If it fails for some reason, the error from the server is returned formatted as XML.
At the moment, the only way I figure I can deal with this is the not attempt to use the specific XML/JSON RequestOperations, and purely treat everything as a plain HTTP request, and then attempt to parse it manually myself, depending upon what the response looks like.
Sadly, I have no control over the web service, or I'd make sure it was all JSON.
Does anybody have any better suggestions for handling this?
[EDIT]
I guess one way of making it slightly cleaner, would be creating a new subclass of AFHTTPRequestOperation, that handled the detection of content type internally, and then passed back either parsed JSON or a GDataXML object depending upon what was returned from the server.
Thanks
This might not be the cleanest or most optimal solution, but you could do a check with an existing JSON library that the response is in fact valid JSON. If it is, proceed as usual; if it isn't, treat it with your hand-carved parsing solution.
I am looking for the easiest, simplest way to access web APIs that return either JSON or XML, with concurrent requests.
For example, I would like to call the twitter search API and return 5 pages of results at the same time (5 requests). The results should ideally be integrated and returned in one array of hashes.
I have about 15 APIs that I will be using, and already have code to access them individually (using simple a NET HTTP request) and parse them, but I need to make these requests concurrent in the easiest way possible. Additionally, any error handling for JSON/XML parsing is a bonus.
I'd recommend Weary.
It handles multiple simultaneous asynchronous requests by spawning a thread for each request, and with it you can write API connectors that are readable and DRY. On top of that it has a built in .parse method which works with JSON or XML responses.
I am currently putting together a rails-based web application which will only serve and receive data via json and xml. However, some requirements contain the ability to upload binary data (images).
Now to my understanding JSON is not entirely meant for that... but how do you in general tackle the problem of receiving binary files/data over those two entrypoints to your application?
I suggest encoding the binary data in something like base64. This would make it safe to use in XML or JSON format.
http://en.wikipedia.org/wiki/Base64
maybe you could have a look on Base64 algorithm.
This is used to "transform" everything to ascii char.
You can code and decode it. It's used for webservices, or even on dotnet Serialization.
Hope this helps a little.
Edit: I saw "new post", while posting, someone was faster.Rails base64
If you are using Rails and json and xml than you are using HTTP. "POST" is a part of HTTP and is the best way to transform binary data. Base64 is a very inefficient way of doing this.
If your server is sending data, I would recommend putting a path to the file on the server in the XML or JSON. That way your server doesn't have to base64 encode the data and your client, which already supports HTTP GET, can pull down the data without decoding it. (GET /path/to/file)
For sending files, have your server and/or client generate a unique file name and use a two step process; the client will send the xml or json message with fileToBeUploaded: "name of file.ext" and after sending the message will POST the data with the aforementioned filename. Again, client and server won't have to encode and decode the data. This can be done with one request using a multi-part request.
Base64 is easy but will quickly chew up CPU and/or memory depending on the size of the data and frequency of requests. On the server-side, it's also not an operation which is cached whereas the operation of your web server reading the file from disk is.
If your images are not too large, putting them in the database with a RoR :binary type makes a lot of sense. If you have database replicas, the images get copied for free to the other sites, there's no concern about orphaned or widowed images, and the atomic transaction issues become far simpler.
On the other hand, Nessence is right that Base64, as with any encoding layer, does add network, memory and CPU load to the transactions. If network bandwidth is your top issue, make sure your web service accepts and offers deflate/gzip compressed connections. This will reduce the cost of the Base64 data on the network layer, albeit at the cost of even more memory and CPU load.
These are architectural issues that should be discussed with your team and/or client.
Finally, let me give you a heads up about RoR's XML REST support. The Rails :binary database type will become <object type="binary" encoding="base64">...</object> XML objects when you render to XML using code like this from the default scaffolding:
def show
#myobject = MyObject.find(:id)
respond_to do |format|
format.xml { render => #myobject }
end
end
This works great for GET operations, and the PUT and POST operations are about as easy to write. The catch is the Rails PUT and POST operations don't accept the same tags. This is because the from_xml code does not interpret the type="binary" tag, but instead looks for type="binaryBase64". There is a bug with a patch at the Rails lighthouse site to correct this.