Changes for page 1. SearchTourPackages

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -6,11 +6,32 @@
6	6
7	7	= Method Description =
8	8
9		-Tour package mean, tour with hotel and flight together. Using this method gives data about full package availability with flight and hotel options.
	9	+Tour package mean, tour with hotel and flight  together In case of variation also with transfer option. Using this method gives data about full package availability with flight and hotel options.
10	10
11	11	It's possible to receive data as current dates, also in date ranges using parameter  "stayDays": 0,   "stayDaysTo": 0. the maximum difference between the days can be 7. Below you can see examples.
12	12
13	13
	14	+in more  details:
	15	+
	16	+A tour package encapsulates a bundled offering that includes both hotel accommodations and flight arrangements. In certain variations, it may also incorporate transfer options, providing a comprehensive travel solution. The method detailed herein facilitates the retrieval of data concerning the complete availability of such tour packages, including pertinent flight and hotel options.
	17	+
	18	+**Data Retrieval Parameters:**
	19	+
	20	+* **Parameter Usage**: To query package data, the system utilizes the following parameters within the request payload:
	21	+** stayDays: Defines the minimum duration of stay (in days) as part of the tour package. The value is set to 0 by default, indicating no minimum duration constraint.
	22	+** stayDaysTo: Specifies the maximum duration of stay (in days) allowable within the package offerings. A default value of 0 implies no maximum limit; however, the system enforces a maximum duration difference of 7 days between stayDays and stayDaysTo.
	23	+
	24	+**Constraints:**
	25	+
	26	+* The system imposes a constraint wherein the difference between stayDays and stayDaysTo cannot exceed 7 days. This limit is designed to refine search results and maintain query performance.
	27	+
	28	+**Example Requests:** Below are examples illustrating how to structure requests for retrieving tour package data, utilizing the stayDays and stayDaysTo parameters to define the desired range of stay durations.
	29	+
	30	+(Note: Actual example requests are not included in this response but should typically be provided here, showcasing the structure and format of API calls or query parameters used to fetch the tour package data.)
	31	+
	32	+This documentation aims to guide developers in effectively querying for tour package options, employing specified parameters to tailor the search according to the duration of stay requirements.
	33	+
	34	+
14	14	== Endpoint URL - [POST] ==
15	15
16	16	{{info}}
...	...	@@ -862,7 +862,6 @@
862	862	|totalCount|integer|The total count of packages.
863	863	|error|boolean|Indicates whether there was an error.
864	864
865		-
866	866	=== Paging and Caching ===
867	867
868	868	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:
...	...	@@ -894,6 +894,58 @@
894	894	{{/code}}
895	895
896	896
	917	+**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.
	918	+
	919	+**Initial Request:**
	920	+
	921	+* **Purpose**: The first request initiates the paging process and is designed to fetch the initial set of data without utilizing a pagingId.
	922	+* **Parameters**:
	923	+** pagingId: Should be set to an empty string ("") to indicate that this is the initial request.
	924	+** pageNumber: Indicates the specific page of data to retrieve, starting with 1.
	925	+** pageRowCount: Specifies the number of results to be included on each page.
	926	+
	927	+**Example - First Request**:
	928	+
	929	+{{{{
	930	+ "pagingId": "",
	931	+  "pageNumber": 1,
	932	+  "pageRowCount": 10
	933	+}
	934	+}}}
	935	+
	936	+
	937	+**Subsequent Requests with Caching:**
	938	+
	939	+* **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.
	940	+* **Cache Utilization**:
	941	+** Upon receiving a response, a pagingId value is provided. This pagingId should be used in subsequent requests to reference the cached data.
	942	+** To navigate through the dataset, adjust the pageNumber while keeping the pagingId constant.
	943	+** To refresh the dataset and clear the cache, initiate a new request without a pagingId.
	944	+
	945	+
	946	+**Example - Request with Caching**:
	947	+
	948	+{{{ {
	949	+ "pagingId": "80",
	950	+ "pageNumber": 2, // Adjusted to fetch the next page
	951	+ "pageRowCount": 10
	952	+ }
	953	+}}}
	954	+
	955	+
	956	+**Cache Management:**
	957	+
	958	+* 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.
	959	+
	960	+**Implementation Notes**:
	961	+
	962	+* The paging and caching mechanism significantly enhances data retrieval efficiency by minimizing server load and optimizing response times.
	963	+* Developers should ensure that the pagingId is correctly managed between requests to maintain session continuity and data consistency.
	964	+
	965	+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.
	966	+
	967	+
	968	+
897	897	=== Search parameter options ===
898	898
899	899	in the request body it's available to filter search results with parameters. parameter examples: