Anyone know the latencies associated with an URL request?

Are we talking 15ms range? 150ms range? 600ms-1s range?

Also, can we access binary blobs/files/images via this API? It seems the max file size of an asset field is 15mb, which is smaller than a Raw photo.

Yes, you can access blobs too. I've been using the HTTP API (the one that backs CloudKitJS) to process data in app engine. So far I just used the JS API token for authentication. Records with an associated blob asset provide a temporary accessible URL to the asset which is usually stored on S3.

Not sure about latency of the requests, never had a problem with that. More often the problem was that I had confirmation my client software had written data to CloudKit but it might take a while before the server can actually query for it. (Could be an indexing delay haven't checked if the object is immediately available using the object ID)

This is a good step. I expect to see a whole slew of cloudkit dashboard services pop up soon.

By coincidence, I was trying to test out this exact thing yesterday and was having trouble with authentication. Does anyone know what they mean by "ISO8601" in their instructions for building an HTTP API request[1]? AFAIK there are a few different date formats that would qualify (e.g. with or without hyphens).

[1] https://developer.apple.com/library/ios/documentation/DataMa...

An example date format is 2016-01-25T22:15:43Z. Also note that you don't have to manually configure and sign the requests yourself, you can simply use CloudKit JS with Node.js. A sample script has been published at https://developer.apple.com/library/ios/samplecode/CloudAtla...

Thanks, though I'm still getting authentication errors. I don't want to use the JS library since I'm not working in Javascript.

I'd kill for a working code sample, in any language. I tried looking at the JS source, but it's minified and thus quite hard to read.

The answers here might be helpful: http://stackoverflow.com/questions/35247436/cloudkit-server-...

I happen to be working on a client in C# at the moment, I'll open source it soon.

About 3-4 years too late. This should have been released with iOS5/iCloud - when it might have been useful.

CloudKit JS has only been released 6 months ago and that was my biggest request concerning it, I'm happy they didn't wait until WWDC 2016 to add this support.

Yeah - nobody was using parse, which proves there is no demand for this kind of thing.

/s

What makes you say no one was using it (my understanding is the opposite), and that most certainly does not lead to your conclusion even if the first part is true.

Just because FB killed it doesn't mean it no one was using it...

The "/s" indicates sarcasm.

Parse's advantage was not only convenience but multiplatform.

CloudKit has a javascript sdk...

Which is based around a HTTP API (also documented by Apple). Not that hard to wrap that in an easily usable SDK for other platforms.

It doesn't turn out to have been.