I'm trying to understand how to properly use NSURLSession for my scenario, reading through specification, need more clarification..
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/URLLoadingSystem/Articles/UsingNSURLSession.html#//apple_ref/doc/uid/TP40013509-SW1
My server API is very simple. I use protobufs for data communication and message payload very small, turnaround very quick. From data standpoint it's just plain binary data being transferred.
Server supports only POST request and responds with data.
So, it goes like this:
- POST request with custom headers and binary payload
- server responds with message and binary payload (response also might include custom headers)
From what I see in documentation data tasks is exactly what I need, but they say
Data tasks send and receive data using NSData objects. Data tasks are
intended for short, often interactive requests from your app to a
server. Data tasks can return data to your app one piece at a time
after each piece of data is received, or all at once through a
completion handler. Because data tasks do not store the data to a
file, they are not supported in background sessions
So, I left with download and upload tasks and they go into a file. How do I go about achieving what I need? Sounds like I should use upload task, but will I get response data back?
ok. I decided not to delete my question in case someone else needs this info.
Same documentation article says:
Uploading a File Using a Download Task To upload body content for a
download task, your app must provide either an NSData object or a body
stream as part of the NSURLRequest object provided when it creates the
download request.
If you provide the data using a stream, your app must provide a
URLSession:task:needNewBodyStream: delegate method to provide a new
body stream in the event of an authentication failure. This method is
described further in “Uploading Body Content Using a Stream.”
The download task behaves just like a data task except for the way in
which the data is returned to your app.
Related
I have a Rails API which can handle requests from the clients. Clients use that API to perform analysis of their data. Client POSTs the data to API, API checks if that data have been analysed before. If so API just respond with analysis result. If the data haven't been analyzed before API:
Tells client that analysis started.
Establishes the connection with analyzing microservice.
Performs asynchronous (or deferred or i don't know) request to the analyzing microservice and waiting for response. The analysis takes much time so neither the API nor the microservice should be blocked while doing it.
When the response from analyzing microservice is returned API hands it to the client.
The main issue for me is to set up things such way that client could receive somehow the message "Your data had been sent to analysis" right after he performed the request. And then when analysis will be done client could receive its result.
The question is what approach I have to use in that case? Async responses, deferred responses, something else? And what known solutions could help me with that? Any gems?
I'm new to that stuff so I'm really sorry if I ask dumb questions.
If using HTTP you can only have one response to every request. To send multiple responses, i.e. "work in progress", then later the "results", you would need to use a different protocol, e.g. web sockets.
Since HTTP is so very common I'd stick with that in combination with background jobs. There are a couple of options which spring to mind.
Polling: The API kicks off a background jobs (to call the microservice) and responds to the client with a URL which the client can ping periodically for the result. The URL would respond with some kind of "work in progress" status until the result is actually ready). The URL would need to include some kind of id so the API can lookup the background job.
The API would potentially have two URLS; /api/jobs/new and /api/jobs/<ID>. They would, in Rails, map to a controller new and show action.
Webhooks: Have the client include a URL of its own in the request. Once the result is available have the background job hit the given URL with the result.
Either way, if using HTTP, you will not be able to handle the whole thing within a request/response, you will have to use some kind of background processing (so request to the microservice happens in a different process). You could look at Sidekiq, for example.
Here is an example for polling:
URL: example.com/api/jobs/new
web app receives client request
generates a unique id for the request, SecureRandom.uuid.
starts a background job (Sidekiq) passing in the uuid and any other parameters needed
respond with URL such as example.com/api/jobs/
--
background job
sends request to microservice API and waits for response
saves result to database with uuid
--
URL: example.com/api/jobs/UUID
look in database for UUID, if not found respond that job is "in progress". If found return result found in database.
Depending on what kind of API you use. I assume your clients interact via HTTP.
If you want to build an asynchronous API over HTTP the first thing that you should do: accept the request, create a job, handle it in the background and immediately return.
For the client to get the response you have to 2 options:
Implement a status endpoint where clients can periodically poll the status of the job
Implement a callback via webhooks. So the client has to provide a URL which you then call after you're done.
A good start for background processing is the sidekiq gem or more general ActiveJob that ships with Rails.
I know it is a basic Question. Does a POST Json Request for update in User interface actually Post data in to database or just simulates the load for Post data without actually posting in database. But can someone please clarify
An HTTP Post request with the mandatory body (can be parameters, JSON, XML etc.), is intended to upload the data into server (upload images, Sign Up etc.), or to post data which server wants (to validate Sign in etc., not necessarily insert into the DB). So, it is basically how Server treats the data and the purpose.
If server puts the received data into the database, when performed the action using the browser, then the same operation expected when performed through JMeter also irrespective of the type of body data (JSON, XML etc). So, If you post the JSON data, it must be inserted into DB.
In DB, One thing to note is that server, either can directly dump the JSON data as JSON type itself or parse the JSON data and take the required values and store them in the Database. It depends on how the server is implemented.
So, how the server is implemented, it should behave the same way, whether you send the request from the browser or JMeter.
It depends on implementation. From JMeter's perspective API endpoint is yet another URL, JMeter sends a request to it, measures time between request and response and marks result as passed or failed depending whether HTTP Status Code is below 400 or not.
So it is up to you to check:
What does API endpoint actually do
What is correct request syntax (mandatory arguments, headers, cookies, URL parameters, whatever)
What is the expected result.
Optionally, what happens if "bad" request is being sent.
When designing a JMeter test always run it with 1-2 users and View Results Tree listener enabled to ensure that it does what it is supposed to be doing.
Coming back to your question: if HTTP response code is below 400, JMeter will mark sampler as successful, it won't check response body or database so I would recommend using the following test elements for confirmation:
JDBC PostProcessor - to check whether database was updated as a result of the request or not.
Response Assertion - to check that API response doesn't have errors, status code, variables, returned from the database, etc.
I want to create a server on iOS with GCDWebServer, which will accept request to localhost, and then, draw the data from another url (a video file) and stream the data to the response. I intend to use plain NSURLConnection, and in the didReceiveData of the NSURLConnection callback, I want to pass this data to the GCDWebServerResponse.
I am having a hard time to figure out how can I keep the connection from a request open, so that I can initiate another request w/ NSURLConnection, and start serving data to the response.
Is there any way I can do that? Do I need to create a new subclass of GCDWebServerStreamedResponse?
Thank you in advance.
You don't need to subclass GCDWebServerStreamedResponse but simply instantiate it and use the GCDWebServerAsyncStreamBlock callback.
In the callback, create your NSURLConnection and have it run asynchronously. Then whenever new data is available (e.g. from -didReceiveData:), pass it through using the GCDWebServerBodyReaderCompletionBlock and when there is no more data available, pass an empty NSData.
See the "Advanced asynchronous version" in the GCDWebServer README for a similar concept.
I'm starting an iOS app that consume a Restful API.
I have control over that API and I'm confusing with the caching policies.
To begin, I only need caching a concrete resoruce, but the problem is that resource can change when I insert new record in the database.
Then, how can I tell to the application "Hey! Make the request only if there have been changes and if not, you get the data from the cache!"
I'm using AFNetworking to make requests..
You'll have to make a decision on either server or client side and build your own protocol.
Example:
You could send the server JSON post request which contains the 'version' of the data you have in the app. On the server-side you will increment the version number each time the data gets refreshed. If the version number does not match at server-side, the server will respond with all new data, else the server responds JSON with 'up to date'
EDIT:
If you are looking for an HTTP response saying that the data is not modified. This is done on server side. You'll have to implement this in the server.
I’d like some input on whether there is a better design pattern to use for my iOS app, which uses a REST model to communicate asynchronously with a Django back end.
The server can presently return three types of responses to requests:
a JSON object
a server status code integer
a long Django error message
When an action is performed in the iOS app that requires data from the server, my design pattern looks like this:
An observer is added to notification center, specifying a method that can process the server response
The method puts together and sends a NSURLConnection
A NSURLConnection delegate method receives the response, does some interpretation to check what kind of server response it is, and then posts the appropriate notification to the notification center
This triggers the response method to run, processing the response
My issue with this pattern is that there are a large number of methods written to send and receive individual request and response types. For instance, if I am requesting an item list, I need to add several observers to the notification center, one to process a user list, one to process a blank user list, and one to process errors. Then I need to write custom methods for each one of those three to perform the appropriate actions and remove the observers, based on what kind of response the server sends.
Furthermore, the NSURLConnection delegate ends up being fairly complex, because I’m trying to interpret what type of a response was received (what types of items were in the list received?) without much context of what was requested, to make sure I don’t call the wrong response method when a server message comes back.
I am fairly new to both iOS programming and to REST programming, so I may be missing something obvious. Any advice or links to resources is appreciated.
I'd initially look at using RestKit to abstract your code away from the network comms so you can worry more about the data model and high level requests. Secondly, I wouldn't use notifications for this as it will likely get messy and be very hard to manage multiple simultaneous requests - delegation or block callbacks will be much better for this.
Your REST implementation is mostly server side, and emprirically you'd be passing and receiving binary. There are factors to consider, including whether you are utilizing HTTP.
Working with JSON with NSJSONSerialization class, and NSURLConnection keeps your program more lean and mean.