1703878296
usingOraclize合约可以代替OraclizeI和OraclizeAddrResolverI合约。事实上，usingOraclize使得OraclizeI和OraclizeAddrResolverI合约的调用变得方便，也就是说，它提供了更简单的API。也可以直接调用OraclizeI和OraclizeAddrResolverI合约。读者可以学习这些合约的源代码以发现所有可用API，本书中，我们只学习最必需的那些。
1703878297
1703878298
下面来看设定proof类型、设定proof存储位置、进行查询、获取查询费用等的方法。
1703878299
1703878300
1.设置证明类型和存储位置
1703878301
1703878302
无论是否需要来自TLSNotary的proof，必须在发出查询之前指定proof类型和proof存储位置。
1703878303
1703878304
如果不需要proof，就把下面的代码放入合约：
1703878305
1703878306
1703878307
1703878308
1703878309
如果需要proof，就把下面的代码放入合约：
1703878310
1703878311
1703878312
1703878313
1703878314
目前，proofStorage_IPFS是唯一可用的proof存储位置，也就是说，TLSNotary proof只存储在IPFS中。
1703878315
1703878316
每次只能执行这些方法中的任意一个，例如在constructor中或者在其他任何时间（比如只需要某些特定查询的proof）。
1703878317
1703878318
2.发送查询
1703878319
1703878320
为了向Oraclize发送一个查询，需要调用oraclize_query函数。这个函数至少需要两个实参，即数据源和给定数据源的输入值。数据源实参不区分大小写。
1703878321
1703878322
oraclize_query函数的一些基础示例如下：
1703878323
1703878324
1703878325
1703878326
1703878327
上述代码的执行过程如下：
1703878328
1703878329
·如果第一个实参是字符串，就假定它是数据源，第二个实参就假定为数据源的输入条件。在第一个调用中，数据源是WolframAlpha，我们向它发送的查询是0和100之间的随机数。
1703878330
1703878331
·在第二个调用中，向第二个实参中所示的URL发出HTTP GET请求。
1703878332
1703878333
·在第三个调用中，从IPFS获取QmdEJwJG1T9rzHvBD8i69HHuJaRgXRKEQCP7Bh1BVttZbU文件的内容。
1703878334
1703878335
·如果数据源之后的两个连续实参是字符串，就假定它是POST请求。在最后一个调用中，发出HTTP POST请求到https://xyz.io/makePayment进行支付。POST请求内容是第三个实参中的字符串。Oraclize十分智能，能够检测基于字符串格式的content-type标头。
1703878336
1703878337
3.预约查询
1703878338
1703878339
如果想让Oraclize在未来某一预订时间执行查询，就指定从当前时间算起的延迟（以秒计算）作为第一个实参。示例如下：
1703878340
1703878341
1703878342
1703878343
1703878344
Oraclize将在看到上述查询60s之后进行查询。所以，如果第一个实参是数字，就假定我们在预约查询。
1703878345