Skip to Content

Changes for page 1. SearchHotelPrices

Last modified by Giorgi Mdivnishvili on 2024/11/06 10:47
From version 16.1
edited by Giorgi Mdivnishvili
on 2024/11/06 10:45
Change comment: There is no comment for this version
To version 14.1
edited by Giorgi Mdivnishvili
on 2024/04/11 17:55
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -378,17 +378,6 @@
378 378  During the first request, Paging id must be  empty like this  ( "pagingId": "",)  pagenumber is the number of the page, pagerowcount means number of the given result in one page. So in the first request we can search like this:
379 379  
380 380  
381 -{{code language="Json"}}
382 - {
383 - "isDynamic": false
384 - }
385 -
386 - {
387 - "isDynamic": True
388 - }
389 -{{/code}}
390 -
391 -
392 392  ==== first request ====
393 393  
394 394  {{code language="Json"}}
... ... @@ -413,77 +413,22 @@
413 413  {{/code}}
414 414  
415 415  
416 -**Overview:** The Paging and Caching mechanism is designed to efficiently manage data retrieval in a paginated format. This mechanism is essential for handling large datasets by dividing the data into manageable pages, thereby optimizing the performance and scalability of data retrieval operations.
417 417  
418 -**Initial Request:**
419 -
420 -* **Purpose**: The first request initiates the paging process and is designed to fetch the initial set of data without utilizing a pagingId.
421 -* **Parameters**:
422 -** pagingId: Should be set to an empty string ("") to indicate that this is the initial request.
423 -** pageNumber: Indicates the specific page of data to retrieve, starting with 1.
424 -** pageRowCount: Specifies the number of results to be included on each page.
425 -
426 -**Example - First Request**:
427 -
428 -{{{{
429 - "pagingId": "",
430 -  "pageNumber": 1,
431 -  "pageRowCount": 10
432 -}
433 -}}}
434 -
435 -
436 -**Subsequent Requests with Caching:**
437 -
438 -* **Purpose**: Following the initial data retrieval, subsequent requests utilize the pagingId obtained from the previous response. This pagingId serves as a cache identifier, enabling the system to quickly access the relevant dataset and efficiently paginate through the data.
439 -* **Cache Utilization**:
440 -** Upon receiving a response, a pagingId value is provided. This pagingId should be used in subsequent requests to reference the cached data.
441 -** To navigate through the dataset, adjust the pageNumber while keeping the pagingId constant.
442 -** To refresh the dataset and clear the cache, initiate a new request without a pagingId.
443 -
444 -**Example - Request with Caching**:
445 -
446 -{{{ {
447 - "pagingId": "80",
448 - "pageNumber": 2, // Adjusted to fetch the next page
449 - "pageRowCount": 10
450 - }
451 -}}}
452 -
453 -
454 -**Cache Management:**
455 -
456 -* Clearing the cache and fetching a fresh set of data requires sending a new request with the pagingId parameter omitted or set to an empty string. This action resets the pagination and caching context.
457 -
458 -**Implementation Notes**:
459 -
460 -* The paging and caching mechanism significantly enhances data retrieval efficiency by minimizing server load and optimizing response times.
461 -* Developers should ensure that the pagingId is correctly managed between requests to maintain session continuity and data consistency.
462 -
463 -This documentation outlines the procedural framework for implementing a robust paging and caching strategy within data retrieval systems, detailing parameter usage and operational best practices for both initial and subsequent data fetch operations.
464 -
465 -
466 -
467 -== Update ==
468 -
469 -To identify whether the returned result is from a dynamic or static channel, a field 'isDynamic' has been added to the response. This field can have a value of TRUE or FALSE. Accordingly, if the hotel is from a dynamic channel, the response will show TRUE.
470 -
471 -
472 472  == Important ==
473 473  
474 474  {{error}}
475 -=== Implementing Authorization in Subsequent Requests ===
409 +It's Important to in every other request header, put Auth token
476 476  
477 -For every API request after the initial authentication, it's crucial to include the authorization token in the request header. This ensures your requests are authorized and can access the necessary resources. Here's how to properly include your token:
411 +**Key **- Authorization
478 478  
479 -* **Header Key:** Authorization
480 -* **Header Value:** Bearer [Your Token Here] - Use the bearer token provided in the initial authentication response. The authorization type should be specified as Bearer Token.
413 +**Value **- Bearer Token what is given in this response.
481 481  
482 -Additionally, to ensure your requests are properly formatted and recognized, include the following headers:
483 483  
484 -* **Content-Type:** Specify this header as application/json to indicate the format of the request body.
485 -* **Header Key:** X-nugios-timezone
486 -* **Header Value:** 240 - Adjust this value to match your local timezone offset in minutes.
416 +**also note in headers that:**
487 487  
488 -Incorporating these headers with their respective values is essential for the successful processing of your API requests.
418 +Content-Type - application/json
419 +
420 +**Key - **X-nugios-timezone
421 +
422 +**Value **- 240
489 489  {{/error}}