mirror of
https://github.com/MarshalX/telegram-crawler.git
synced 2024-12-29 15:59:13 +01:00
Update content of files
This commit is contained in:
parent
a4883b6a56
commit
41e9ec97ac
1 changed files with 15 additions and 17 deletions
|
@ -41,42 +41,40 @@
|
|||
|
||||
<div id="dev_page_content"><!-- scroll_nav -->
|
||||
|
||||
<h3><a class="anchor" href="#layers" id="layers" name="layers"><i class="anchor-icon"></i></a>Layers</h3>
|
||||
<h3><a class="anchor" name="layers" href="#layers"><i class="anchor-icon"></i></a>Layers</h3>
|
||||
<p>Versioning in the API is supported by so-called TL layers.</p>
|
||||
<p>The need to add a new object constructor or to add/remove a field in a constructor creates a backwards compatibility problem for previous versions of API clients. After all, simply changing a constructor in a schema also changes its number. To address this problem, each schema update is separated into a layer.
|
||||
A layer is a collection of updated methods or constructors in a TL schema. Each layer is numbered with sequentially increasing numbers starting with 2. The first layer is the base layer -- the TL schema without any changes.</p>
|
||||
<p>The need to add a new object constructor or to add/remove a field in a constructor creates a backwards compatibility problem for previous versions of API clients. After all, simply changing a constructor in a schema also changes its number. To address this problem, each schema update is separated into a layer.<br>A layer is a collection of updated methods or constructors in a TL schema. Each layer is numbered with sequentially increasing numbers starting with 2. The first layer is the base layer — the TL schema without any changes.</p>
|
||||
<p>There is helper method to let the API know that a client supports Layer <code>layer</code>:</p>
|
||||
<pre><code>invokeWithLayer#da9b0d0d {X:Type} layer:int query:!X = X;</code></pre>
|
||||
<p>The helper method <strong><a href="/method/invokeWithLayer">invokeWithLayer</a></strong> can be used only together with <a href="/method/initConnection">initConnection</a>: the present layer will be saved with all other parameters of the client and future calls will be using this saved value. <a href="#saving-client-info">See more below.</a>.</p>
|
||||
<h4><a class="anchor" href="#list-of-available-layers" id="list-of-available-layers" name="list-of-available-layers"><i class="anchor-icon"></i></a><a href="/api/layers">List of Available Layers</a></h4>
|
||||
<h3><a class="anchor" href="#saving-client-info" id="saving-client-info" name="saving-client-info"><i class="anchor-icon"></i></a>Saving Client Info</h3>
|
||||
<h4><a class="anchor" name="list-of-available-layers" href="#list-of-available-layers"><i class="anchor-icon"></i></a><a href="/api/layers">List of Available Layers</a></h4>
|
||||
<h3><a class="anchor" name="saving-client-info" href="#saving-client-info"><i class="anchor-icon"></i></a>Saving Client Info</h3>
|
||||
<p>It is possible to save information about the current client on the server in conjunction with an authorization key. This may help eliminate client-side problems with certain releases on certain devices or with certain localizations, as well as eliminate the need for sending layer information in each call.</p>
|
||||
<p>The helper method <strong><a href="/method/initConnection">initConnection</a></strong> accepts client parameters. This method must be called when first calling the API after the application has restarted or in case the value of one of the parameters could have changed.</p>
|
||||
<p><strong>initConnection</strong> must also be called after each <a href="/method/auth.bindTempAuthKey">auth.bindTempAuthKey</a>.</p>
|
||||
<p>When calling this method, the current layer used by the client is also saved (the layer in which <a href="/method/initConnection">initConnection</a> was wrapped is used). After a successful call to <a href="/method/initConnection">initConnection</a> it is no longer necessary to wrap each API call in <strong>invokeWithLayerN</strong>.</p>
|
||||
<h3><a class="anchor" href="#disabling-updates" id="disabling-updates" name="disabling-updates"><i class="anchor-icon"></i></a>Disabling updates</h3>
|
||||
<h3><a class="anchor" name="disabling-updates" href="#disabling-updates"><i class="anchor-icon"></i></a>Disabling updates</h3>
|
||||
<pre><code>invokeWithoutUpdates#bf9459b7 {X:Type} query:!X = X;</code></pre>
|
||||
<p><a href="/method/invokeWithoutUpdates">invokeWithoutUpdates</a> can be used to invoke a request without subscribing the used connection for <a href="/api/updates">updates</a> (this is enabled by default for <a href="/api/files">file queries</a>).</p>
|
||||
<h3><a class="anchor" href="#sequential-calls" id="sequential-calls" name="sequential-calls"><i class="anchor-icon"></i></a>Sequential Calls</h3>
|
||||
<h3><a class="anchor" name="sequential-calls" href="#sequential-calls"><i class="anchor-icon"></i></a>Sequential Calls</h3>
|
||||
<p>Sometimes a client needs to transmit several send message method calls to the server all at once in a single message or in several consecutive messages. However, there is a chance that the server may execute these requests out of order (queries are handled by different servers to improve performance, which introduces a degree of randomness to the process).</p>
|
||||
<p>There are helper methods for making several consecutive API calls without wasting time waiting for a response:</p>
|
||||
<div class="richcode">
|
||||
<p><a href="/method/invokeAfterMsg">invokeAfterMsg</a>#cb9f372d {X:Type} msg_id:long query:!X = X;<br>
|
||||
<a href="/method/invokeAfterMsgs">invokeAfterMsgs</a>#3dc4b4f0 {X:Type} msg_ids:Vector<long> query:!X = X; </long></p>
|
||||
<p><a href="/method/invokeAfterMsg">invokeAfterMsg</a>#cb9f372d {X:Type} msg_id:long query:!X = X;<br><a href="/method/invokeAfterMsgs">invokeAfterMsgs</a>#3dc4b4f0 {X:Type} msg_ids:Vector<long> query:!X = X;</p>
|
||||
</div>
|
||||
<p>They may be used, for example, if a client attempts to send accumulated messages after the Internet connection has been restored after being absent for a long time. In this case, the 32-bit number <code>0xcb9f372d</code> must be added before the method number in each call, followed by a 64-bit message identifier, msg_id, which contains the previous call in the queue.
|
||||
The second method is similar, except it takes several messages that must be waited for.</p>
|
||||
<p>If the waiting period exceeds 0.5 seconds (this value may change in the future) and no result has appeared, the method will be executed just the same. If any of the queries returns an error, all its dependent queries will also return the <a href="/api/errors#400-bad-request">400 MSG_WAIT_FAILED</a> error.</p>
|
||||
<h4><a class="anchor" href="#helper-method-sequence" id="helper-method-sequence" name="helper-method-sequence"><i class="anchor-icon"></i></a>Helper Method Sequence</h4>
|
||||
<p>They may be used, for example, if a client attempts to send accumulated messages after the Internet connection has been restored after being absent for a long time. In this case, the 32-bit number <code>0xcb9f372d</code> must be added before the method number in each call, followed by a 64-bit message identifier, msg_id, which contains the previous call in the queue.<br>The second method is similar, except it takes several messages that must be waited for.</p>
|
||||
<p>If the waiting period exceeds 0.5 seconds (this value may change in the future) and no result has appeared, the method will be executed just the same." => "If the waiting period exceeds 0.5 seconds (this value may change in the future) and no result has appeared, the method will return the <a href="/api/errors#400-bad-request">400 MSG_WAIT_TIMEOUT</a> error.</p>
|
||||
<h4><a class="anchor" name="helper-method-sequence" href="#helper-method-sequence"><i class="anchor-icon"></i></a>Helper Method Sequence</h4>
|
||||
<p><strong>Important:</strong> if the helper methods <strong>invokeAfterMsg</strong> / <strong>invokeAfterMsgs</strong> are used together with <strong>invokeWithLayerN</strong> or other helper methods, <strong>invokeAfterMsg</strong> / <strong>invokeAfterMsgs</strong> must always be the outermost wrapper.</p>
|
||||
<h3><a class="anchor" href="#data-compression" id="data-compression" name="data-compression"><i class="anchor-icon"></i></a>Data Compression</h3>
|
||||
<h3><a class="anchor" name="data-compression" href="#data-compression"><i class="anchor-icon"></i></a>Data Compression</h3>
|
||||
<p>We recommend using gzip compression when making method calls in order to reduce the amount of network traffic.</p>
|
||||
<p>The schema and constructor information are given in the <a href="/mtproto/service_messages#packed-object">protocol documentation</a>.</p>
|
||||
<h4><a class="anchor" href="#data-compression-when-making-a-call" id="data-compression-when-making-a-call" name="data-compression-when-making-a-call"><i class="anchor-icon"></i></a>Data Compression when Making a Call</h4>
|
||||
<h4><a class="anchor" name="data-compression-when-making-a-call" href="#data-compression-when-making-a-call"><i class="anchor-icon"></i></a>Data Compression when Making a Call</h4>
|
||||
<p>Before transmitting a query, the string containing the entire body of the serialized high-level query (starting with the method number) must be compressed using gzip. If the resulting string is smaller than the original, it makes sense to transmit the <a href="/mtproto/service_messages#pakovannyy-obekt">gzip_packed</a> constructor.</p>
|
||||
<p>There is no point in doing the above when transmitting binary multimedia data (photos, videos) or small messages (up to 255 bytes).</p>
|
||||
<h4><a class="anchor" href="#uncompressing-data" id="uncompressing-data" name="uncompressing-data"><i class="anchor-icon"></i></a>Uncompressing Data</h4>
|
||||
<p>By default, the server compresses the response to any call as well as <a href="/api/updates">updates</a>, in accordance with the rules stated above. If the <a href="/mtproto/service_messages#packed-object">gzip_packed</a> constructor is received as a response in rpc_result, then the string that follows must be extracted and uncompressed. Processing then continues on the resulting new string.</p></div>
|
||||
<h4><a class="anchor" name="uncompressing-data" href="#uncompressing-data"><i class="anchor-icon"></i></a>Uncompressing Data</h4>
|
||||
<p>By default, the server compresses the response to any call as well as <a href="/api/updates">updates</a>, in accordance with the rules stated above. If the <a href="/mtproto/service_messages#packed-object">gzip_packed</a> constructor is received as a response in rpc_result, then the string that follows must be extracted and uncompressed. Processing then continues on the resulting new string.</p>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
|
|
Loading…
Reference in a new issue