Quantum computing in action: IBM's Q experience and the quantum shell game（2）

look_w

Communicate with the IBM Q experience platformOne of the first things we’ll need to do is to send data to the IBM Q                experience platform. Rather than write and rewrite the same code over and                over again, I lumped it into a single function called FetchAPIData. This                way, other functions like the PerformLogin function only need to pass the                relative URL, an HTTP method (post, delete, get etc) and the content (if                posting). FetchApiData will take care of the rest.
It begins by adding the relative portion of the URL to the base URL:                 If we aren’t performing a                delete and if we have a User object, it will also pass the User.id as the                access_token. When deleting, we pass the User.id as a request header                (X-Access-Token) instead of appending the access_token to the URL.
The bulk of the code here is simply building the request message, adding                content, and setting request headers. If we get back a success status                code, we sent our QResult object correctly, and we are done.
Listing 1. Sending our QResult                    object

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

private QResult FetchAPIData(string urlRelativePath,                                HttpMethod httpMethod,                                HttpContent contentToSend)    {        QResult result = new QResult();        //add auth token if we have a user and we arent deleting        if (User != null && httpMethod !=HttpMethod.Delete)           {            urlRelativePath = urlRelativePath +  "&access_token=" + User.id;        }        string url = _baseUrl + urlRelativePath;        Debug.WriteLine("Performing " + httpMethod.ToString() + " to " + url);        if (contentToSend!=null) {            Debug.WriteLine("Sending data " + contentToSend.ReadAsStringAsync().Result);        }        HttpRequestMessage request = new HttpRequestMessage(httpMethod, url);        request.Content = contentToSend;        if (User != null) request.Headers.Add("X-Access-Token", User.id);        using (HttpResponseMessage response = _client.SendAsync(request).Result)            if (response.IsSuccessStatusCode)            {                using (HttpContent content = response.Content)                {                    // ... Read the string.                    result.Message = content.ReadAsStringAsync().Result;                    result.Success = response.IsSuccessStatusCode;                                   }            } else            {                result.Message = response.ReasonPhrase;                result.Success = false;            }        return result;    }

And that’s it! POW!
Now that we have figured out how to communicate with the IBM platform, we                need to understand what we must say. Fortunately, it is very simple—there                are two phases.

• The first is an exchange of credentials.
• The second is the transmission of the QASM code itself and the receipt                    of the JSON data representing the result of the quantum code’s                    execution.
• Phase 1. Exchange credentialsLet’s start with the credentials. For the IBM Q experience platform, we                need an API key. To get this key:
• Go to your .
• Click the Regenerate button to have an API key created for you. Figure 2. API token in IBM's Q                            Experience profile page View image at full size
• Now that we have the API token, we pass it to the web service living                    at the “/users/loginWithToken” endpoint. The code listing below shows                    the PerformLogin routine we use to do this.

Listing 2. Passing the API                    token

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

private QResult PerformLogin()         {             if (_token == string.Empty) throw new Exception("A token is required.");             QResult result = new QResult();             HttpContent content= new StringContent("apiToken=" + _token,                                     System.Text.Encoding.UTF8,                                     "application/x-www-form-urlencoded");//CONTENT-TYPE header             result = FetchAPIData("/users/loginWithToken", HttpMethod.Post, content);             if (result.Success)             {                 User = JsonConvert.DeserializeObject<QUser>(result.Message);                 Debug.WriteLine("Logged in and have UserID: " + User.userid);             } else             {                 User = null;             }             return result;         }

There is only one trick here: You do not submit JSON data to this endpoint,                but rather application/x-www-form-urlencoded data. This took                a bit of work to figure out—again, fortunately Fiddler and Wireshark are a                great boon when reverse engineering these kinds of things.
If the token is authenticated, we’ll get back a JSON packet similar to                this:
Listing 3. Returned JSON packet

1 2 3

"{\"id\":\"XXXXXXXXXXXXXXXXXXXXXXXXXX\",\"ttl\":1209600,\"created\": \"2017-10-03T14:51:51.918Z\",\"userId\": \"XXXXXXXXXXXXXXXXXXXXXXXXXXX7999a6\"}"

The value of the userId field is used in subsequent calls to the IBM                platform. It’s good until the time-to-live (ttl) expires—which, in this                simple demonstration code, we ignore. So, in our login step, we                deserialize the userId out of resulting message data, and we stash that                into our global user object.