mirror of
https://github.com/MarshalX/telegram-crawler.git
synced 2024-12-28 07:20:31 +01:00
Update content of files
This commit is contained in:
GitHub Action
parent
c63786db8e
commit
f6203810b6
2 changed files with 44 additions and 46 deletions
|
|
@ -47,28 +47,26 @@
|
|||
<p>Lots of Telegram API methods provide access to potentially large lists of objects, which requires pagination.</p>
|
||||
<p>In order to fetch only relevant subset of results for each request there is a number of available input parameters. Here is a list in order how they are applied in API.</p>
|
||||
<p>Typically, results are returned in reverse chronological order with descending object ID values.</p>
|
||||
<h3><a class="anchor" href="#limit-parameter" id="limit-parameter" name="limit-parameter"><i class="anchor-icon"></i></a><code>limit</code> parameter</h3>
|
||||
<h3><a class="anchor" name="limit-parameter" href="#limit-parameter"><i class="anchor-icon"></i></a><code>limit</code> parameter</h3>
|
||||
<p>A limit on the number of objects to be returned, typically between 1 and 100. When 0 is provided the limit will often default to an intermediate value like ~20.</p>
|
||||
<h3><a class="anchor" href="#offset-based-pagination" id="offset-based-pagination" name="offset-based-pagination"><i class="anchor-icon"></i></a><code>offset</code>-based pagination</h3>
|
||||
<h3><a class="anchor" name="offset-based-pagination" href="#offset-based-pagination"><i class="anchor-icon"></i></a><code>offset</code>-based pagination</h3>
|
||||
<p>For a few methods with mostly static data this parameter allows to skip <code>offset</code> elements from the beginning of list; negative values are ignored.</p>
|
||||
<h3><a class="anchor" href="#offset-id-based-pagination" id="offset-id-based-pagination" name="offset-id-based-pagination"><i class="anchor-icon"></i></a><code>offset_id</code>-based pagination</h3>
|
||||
<h3><a class="anchor" name="offset-id-based-pagination" href="#offset-id-based-pagination"><i class="anchor-icon"></i></a><code>offset_id</code>-based pagination</h3>
|
||||
<p>For most methods where results are real-time data (e.g. any chat history) <code>offset</code> value is not passed directly. Instead it is calculated from the passed <code>offset_id</code> and <code>add_offset</code> parameter values as <code>offsetFromID(offset_id) + add_offset</code>, where <code>offsetFromID(offset_id)</code> is a number of results from the beginning of list up to the result with ID <code>offset_id</code>, inclusive.</p>
|
||||
<p>Sample use cases:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p>Loading 20 messages, older than message with ID <code>MSGID</code>:</p>
|
||||
<p>messages.getHistory({offset_id: MSGID, add_offset: 0, limit: 20})</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Loading 20 messages, newer than message with ID <code>MSGID</code>:</p>
|
||||
<p>messages.getHistory({offset_id: MSGID, add_offset: -20, limit: 20})</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Loading 20 messages around message with ID <code>MSGID</code>:</p>
|
||||
<p>messages.getHistory({offset_id: MSGID, add_offset: -10, limit: 20})</p>
|
||||
</li>
|
||||
<li>Loading 20 messages, older than message with ID <code>MSGID</code>:</li>
|
||||
</ul>
|
||||
<h3><a class="anchor" href="#additional-filtering" id="additional-filtering" name="additional-filtering"><i class="anchor-icon"></i></a>Additional filtering</h3>
|
||||
<pre><code>messages.getHistory({offset_id: MSGID, add_offset: 0, limit: 20})</code></pre>
|
||||
<ul>
|
||||
<li>Loading 20 messages, newer than message with ID <code>MSGID</code>:</li>
|
||||
</ul>
|
||||
<pre><code>messages.getHistory({offset_id: MSGID, add_offset: -20, limit: 20})</code></pre>
|
||||
<ul>
|
||||
<li>Loading 20 messages around message with ID <code>MSGID</code>:</li>
|
||||
</ul>
|
||||
<pre><code>messages.getHistory({offset_id: MSGID, add_offset: -10, limit: 20})</code></pre>
|
||||
<h3><a class="anchor" name="additional-filtering" href="#additional-filtering"><i class="anchor-icon"></i></a>Additional filtering</h3>
|
||||
<p>There is a number of parameters, which are applied to the list after slicing with offset and limit, to reduce the result subset even more:</p>
|
||||
<ul>
|
||||
<li><strong>max_id</strong>: Can be used to only return results with ID strictly smaller than <code>max_id</code> (e.g. message ID)</li>
|
||||
|
|
@ -77,24 +75,25 @@
|
|||
<li><strong>min_date</strong>: Can be used to only return results with are newer than <code>min_date</code>:</li>
|
||||
<li><strong>hash</strong>: See below.</li>
|
||||
</ul>
|
||||
<h3><a class="anchor" href="#hash-generation" id="hash-generation" name="hash-generation"><i class="anchor-icon"></i></a>Hash generation</h3>
|
||||
<p>To further reduce the result subset, there is a mechanism to avoid fetching data if the resulting list hasn't changed from the one stored on client, similar to <a href="https://en.wikipedia.org/wiki/HTTP_ETag">ETag</a>.</p>
|
||||
<h3><a class="anchor" name="hash-generation" href="#hash-generation"><i class="anchor-icon"></i></a>Hash generation</h3>
|
||||
<p>To further reduce the result subset, there is a mechanism to avoid fetching data if the resulting list hasn't changed from the one stored on client, similar to <a href="https://en.wikipedia.org/wiki/HTTP_ETag">ETag</a>.</p>
|
||||
<p>When the client has cached results for API request, it can calculate the <code>hash</code> value for it by taking the result IDs (message IDs or other fields with name <code>id</code>) and using them to compute a 64-bit hash with the following algorithm:</p>
|
||||
<pre><code># Here, ^ indicates a bitwise XOR
|
||||
|
||||
hash = 0
|
||||
for id in ids:
|
||||
hash = hash ^ (id >> 21)
|
||||
hash = hash ^ (id << 35)
|
||||
hash = hash ^ (id >> 4)
|
||||
hash = hash ^ (hash >> 21)
|
||||
hash = hash ^ (hash << 35)
|
||||
hash = hash ^ (hash >> 4)
|
||||
hash = hash + id</code></pre>
|
||||
<p>In some cases, the result container already has a <code>hash</code> field, that can be used instead.</p>
|
||||
<p>When the client passes a correct value, the API will return one of <code>*NotModified</code> constructors, e.g. <a href="/constructor/messages.messagesNotModified">messages.messagesNotModified</a> instead of the actual results.</p>
|
||||
<h3><a class="anchor" href="#example-methods" id="example-methods" name="example-methods"><i class="anchor-icon"></i></a>Example methods</h3>
|
||||
<h3><a class="anchor" name="example-methods" href="#example-methods"><i class="anchor-icon"></i></a>Example methods</h3>
|
||||
<ul>
|
||||
<li><a href="/method/messages.getHistory">messages.getHistory</a> supports all result navigation parameters including message ID hashes and except filters</li>
|
||||
<li><a href="/method/channels.getParticipants">channels.getParticipants</a> supports simple navigation using <strong>limit</strong> and <strong>offset</strong>, along with filtering and <code>hash</code> reducing using the user IDs of returned participants</li>
|
||||
</ul></div>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -47,28 +47,26 @@
|
|||
<p>Lots of Telegram API methods provide access to potentially large lists of objects, which requires pagination.</p>
|
||||
<p>In order to fetch only relevant subset of results for each request there is a number of available input parameters. Here is a list in order how they are applied in API.</p>
|
||||
<p>Typically, results are returned in reverse chronological order with descending object ID values.</p>
|
||||
<h3><a class="anchor" href="#limit-parameter" id="limit-parameter" name="limit-parameter"><i class="anchor-icon"></i></a><code>limit</code> parameter</h3>
|
||||
<h3><a class="anchor" name="limit-parameter" href="#limit-parameter"><i class="anchor-icon"></i></a><code>limit</code> parameter</h3>
|
||||
<p>A limit on the number of objects to be returned, typically between 1 and 100. When 0 is provided the limit will often default to an intermediate value like ~20.</p>
|
||||
<h3><a class="anchor" href="#offset-based-pagination" id="offset-based-pagination" name="offset-based-pagination"><i class="anchor-icon"></i></a><code>offset</code>-based pagination</h3>
|
||||
<h3><a class="anchor" name="offset-based-pagination" href="#offset-based-pagination"><i class="anchor-icon"></i></a><code>offset</code>-based pagination</h3>
|
||||
<p>For a few methods with mostly static data this parameter allows to skip <code>offset</code> elements from the beginning of list; negative values are ignored.</p>
|
||||
<h3><a class="anchor" href="#offset-id-based-pagination" id="offset-id-based-pagination" name="offset-id-based-pagination"><i class="anchor-icon"></i></a><code>offset_id</code>-based pagination</h3>
|
||||
<h3><a class="anchor" name="offset-id-based-pagination" href="#offset-id-based-pagination"><i class="anchor-icon"></i></a><code>offset_id</code>-based pagination</h3>
|
||||
<p>For most methods where results are real-time data (e.g. any chat history) <code>offset</code> value is not passed directly. Instead it is calculated from the passed <code>offset_id</code> and <code>add_offset</code> parameter values as <code>offsetFromID(offset_id) + add_offset</code>, where <code>offsetFromID(offset_id)</code> is a number of results from the beginning of list up to the result with ID <code>offset_id</code>, inclusive.</p>
|
||||
<p>Sample use cases:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p>Loading 20 messages, older than message with ID <code>MSGID</code>:</p>
|
||||
<p>messages.getHistory({offset_id: MSGID, add_offset: 0, limit: 20})</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Loading 20 messages, newer than message with ID <code>MSGID</code>:</p>
|
||||
<p>messages.getHistory({offset_id: MSGID, add_offset: -20, limit: 20})</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Loading 20 messages around message with ID <code>MSGID</code>:</p>
|
||||
<p>messages.getHistory({offset_id: MSGID, add_offset: -10, limit: 20})</p>
|
||||
</li>
|
||||
<li>Loading 20 messages, older than message with ID <code>MSGID</code>:</li>
|
||||
</ul>
|
||||
<h3><a class="anchor" href="#additional-filtering" id="additional-filtering" name="additional-filtering"><i class="anchor-icon"></i></a>Additional filtering</h3>
|
||||
<pre><code>messages.getHistory({offset_id: MSGID, add_offset: 0, limit: 20})</code></pre>
|
||||
<ul>
|
||||
<li>Loading 20 messages, newer than message with ID <code>MSGID</code>:</li>
|
||||
</ul>
|
||||
<pre><code>messages.getHistory({offset_id: MSGID, add_offset: -20, limit: 20})</code></pre>
|
||||
<ul>
|
||||
<li>Loading 20 messages around message with ID <code>MSGID</code>:</li>
|
||||
</ul>
|
||||
<pre><code>messages.getHistory({offset_id: MSGID, add_offset: -10, limit: 20})</code></pre>
|
||||
<h3><a class="anchor" name="additional-filtering" href="#additional-filtering"><i class="anchor-icon"></i></a>Additional filtering</h3>
|
||||
<p>There is a number of parameters, which are applied to the list after slicing with offset and limit, to reduce the result subset even more:</p>
|
||||
<ul>
|
||||
<li><strong>max_id</strong>: Can be used to only return results with ID strictly smaller than <code>max_id</code> (e.g. message ID)</li>
|
||||
|
|
@ -77,24 +75,25 @@
|
|||
<li><strong>min_date</strong>: Can be used to only return results with are newer than <code>min_date</code>:</li>
|
||||
<li><strong>hash</strong>: See below.</li>
|
||||
</ul>
|
||||
<h3><a class="anchor" href="#hash-generation" id="hash-generation" name="hash-generation"><i class="anchor-icon"></i></a>Hash generation</h3>
|
||||
<p>To further reduce the result subset, there is a mechanism to avoid fetching data if the resulting list hasn't changed from the one stored on client, similar to <a href="https://en.wikipedia.org/wiki/HTTP_ETag">ETag</a>.</p>
|
||||
<h3><a class="anchor" name="hash-generation" href="#hash-generation"><i class="anchor-icon"></i></a>Hash generation</h3>
|
||||
<p>To further reduce the result subset, there is a mechanism to avoid fetching data if the resulting list hasn't changed from the one stored on client, similar to <a href="https://en.wikipedia.org/wiki/HTTP_ETag">ETag</a>.</p>
|
||||
<p>When the client has cached results for API request, it can calculate the <code>hash</code> value for it by taking the result IDs (message IDs or other fields with name <code>id</code>) and using them to compute a 64-bit hash with the following algorithm:</p>
|
||||
<pre><code># Here, ^ indicates a bitwise XOR
|
||||
|
||||
hash = 0
|
||||
for id in ids:
|
||||
hash = hash ^ (id >> 21)
|
||||
hash = hash ^ (id << 35)
|
||||
hash = hash ^ (id >> 4)
|
||||
hash = hash ^ (hash >> 21)
|
||||
hash = hash ^ (hash << 35)
|
||||
hash = hash ^ (hash >> 4)
|
||||
hash = hash + id</code></pre>
|
||||
<p>In some cases, the result container already has a <code>hash</code> field, that can be used instead.</p>
|
||||
<p>When the client passes a correct value, the API will return one of <code>*NotModified</code> constructors, e.g. <a href="/constructor/messages.messagesNotModified">messages.messagesNotModified</a> instead of the actual results.</p>
|
||||
<h3><a class="anchor" href="#example-methods" id="example-methods" name="example-methods"><i class="anchor-icon"></i></a>Example methods</h3>
|
||||
<h3><a class="anchor" name="example-methods" href="#example-methods"><i class="anchor-icon"></i></a>Example methods</h3>
|
||||
<ul>
|
||||
<li><a href="/method/messages.getHistory">messages.getHistory</a> supports all result navigation parameters including message ID hashes and except filters</li>
|
||||
<li><a href="/method/channels.getParticipants">channels.getParticipants</a> supports simple navigation using <strong>limit</strong> and <strong>offset</strong>, along with filtering and <code>hash</code> reducing using the user IDs of returned participants</li>
|
||||
</ul></div>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue