V4 Prathirupa

Record API traffic from selected websites and mock network responses for resilience testing.

# V4 Prathirupa V4 Prathirupa is a Chrome and Chromium-based browser extension for web resilience testing, API inspection, and controlled response mocking. It allows developers, QA engineers, automation specialists, and application support teams to observe network traffic generated by selected websites, inspect the requests and responses in detail, save representative calls, and replace future responses with configurable mock data. The extension is designed for testing conditions that are difficult or time-consuming to reproduce with a real backend, such as API errors, empty responses, unusual payloads, service outages, and specific response statuses. A tester can capture a real API call, convert it into a mock rule, and replay a controlled response directly in the browser. V4 Prathirupa works as a local testing tool. It does not require a separate proxy server, backend service, hosted dashboard, or external data platform. Website configuration, captured calls, and mock rules are managed by the extension and stored locally in the browser environment. ## Main Purpose The extension brings API recording and response mocking into the browser where the application is already running. A typical workflow begins with adding a website to the extension, granting the required host permission, and enabling recording for that website. Once recording is active, the extension observes network activity from matching browser tabs. The tester can then use the website normally, navigate through screens, submit forms, open pages, or trigger the specific workflow they want to inspect. After network activity has been captured, the tester opens the V4 Prathirupa workspace. The workspace presents the captured API calls in a searchable, sortable table. Each call can be inspected to understand its method, URL, resource type, status, initiator, size, timing, headers, request body, and response body. A captured call can also become the starting point for a mock rule. V4 Prathirupa pre-fills the rule with information from the real request, including the HTTP method, exact URL, response status, response headers, and response body. The tester can then adjust the values to represent the desired test condition. For example, a successful `200` response can be changed to a `503` service-unavailable response, or a normal JSON payload can be replaced with an empty list, malformed business data, a permission error, or a custom fixture. Once the rule is enabled, matching requests from the selected website can receive the configured response instead of the real response. This makes it possible to test frontend behavior repeatedly and consistently without modifying the production-like service behind the application. ## Popup Control Center The extension popup is the primary control surface for configuring monitored websites and controlling recording activity. It is intentionally focused on operational actions rather than detailed data analysis. Users can add a website in two ways. The first option is to add the active browser tab. This is useful when the tester is already viewing the application they want to inspect. The extension reads the active tab's URL, determines its origin, and requests the necessary host permission. The second option is to enter a website manually, such as `app.example.com` or a complete URL such as `https://app.example.com`. Only regular HTTP and HTTPS websites can be monitored. Browser-internal pages and protected browser contexts, including pages such as `chrome://extensions`, extension pages, DevTools pages, local browser pages, and similar internal URLs, are rejected. This prevents the extension from attempting to attach to pages that cannot or should not be inspected. Adding a website does not automatically begin recording. This separation gives users explicit control over when the debugger is attached and when traffic collection starts. Each configured website appears in the popup with its current state, allowing users to see which websites are available and which ones are actively recording. The popup supports selecting multiple websites and starting or stopping recording in bulk. A user can choose several monitored origins and start recording for all eligible selections at once. Recording can later be stopped for selected websites without removing their configuration or deleting their captured data. A monitored website can also be removed. Removing a website is treated as a complete cleanup action for that website: its recording and mocking attachments are detached, its captured calls are deleted, its saved mock rules are deleted, and its references are removed from the extension settings. This prevents stale identifiers from remaining behind if the same origin is added again later. ## Global Active and Paused State V4 Prathirupa includes a global toggle that controls recording and mocking across the entire extension. The toggle provides a fast way to suspend all active behavior while preserving the user's configuration. When the extension is active, eligible recording sessions can observe traffic and enabled mock rules can intercept matching requests. When the extension is paused, no requests are recorded and enabled mock rules do not replace responses. Website configuration, saved API captures, selected websites, and mock rules remain stored. Pausing also disables mutation-oriented controls that could otherwise change the testing state while the extension is suspended. Workspace actions that create, edit, enable, disable, or delete rules are unavailable during the paused state, and open mock editors are closed. This creates a clear boundary between an active testing session and a temporarily suspended one. Resuming the extension restores the active runtime state. The extension preserves the user's recording intent, so websites that were configured for recording can be attached again when the global toggle is turned back on. The background service worker also rehydrates active attachments after a service-worker restart or browser restart. This prevents the visible recording state from drifting away from the persisted configuration when the Manifest V3 service worker is evicted and later recreated. The extension action icon reflects the global state. An active state uses the enabled icon treatment, while a paused state uses a muted appearance, giving users an immediate visual indication without opening the popup. ## Recording Network Traffic The extension uses the Chrome Debugger API and the DevTools Protocol Network domain to observe network activity in tabs whose origins match configured websites. Recording is attached to active tabs that belong to the selected website origin. The exact URL is preserved so that a captured request can be reproduced precisely. A normalized URL is also generated by replacing numeric path segments with an `:id` placeholder where appropriate. This helps group related endpoints whose URLs differ only by identifiers. For example, URLs such as `/users/101` and `/users/202` can be represented under a common normalized path while retaining their original exact values. The extension can observe more than only API calls. Captured traffic is classified into resource-type categories such as Fetch/XHR, documents, stylesheets, scripts, fonts, images, media, manifests, sockets, WebAssembly, and other resources. This allows the workspace to focus on API-like traffic or investigate broader page behavior. Chrome may display its native debugging infobar while a tab is attached. This is expected behavior caused by the Chrome Debugger API. The infobar is controlled by the browser and cannot be hidden or replaced by the extension. ## Workspace The workspace is the detailed analysis and rule-management interface. It opens in a separate browser tab for inspecting network data and managing mock configurations. The workspace provides two views: 1. Recorded API Calls 2. Saved Mock Rules A website selector allows the user to switch between configured origins. The selected website controls which captures and rules are displayed. The workspace periodically refreshes website and global-state information so that changes made in the popup are reflected without requiring a full reload. If the selected website is currently recording, new activity can be reviewed in the workspace after it is stored. If the global extension state changes to paused, the workspace reflects that state and prevents operations that depend on active recording or mocking. ## Recorded API Calls View The Recorded API Calls view presents captured traffic in a table designed for scanning and comparison. The available columns include the request name or derived endpoint name, HTTP method, response status, resource type, initiator, response size, and timing information. Users can filter calls by URL text. The filter searches the exact request URL and narrows the table to calls that contain the entered value. Resource-type filters can be used independently or together with the URL filter. This makes it easy to focus on Fetch/XHR traffic, scripts, documents, images, or another category. The table can be sorted by several fields: - Name - Method - Status - Type - Initiator - Size - Time Clicking a heading changes the sort column; clicking it again reverses the order. The default ordering emphasizes recently recorded calls. Rows can be selected individually or through a select-all control. Selection supports bulk deletion while respecting the current visible result set. The interface uses confirmation dialogs before destructive actions so the user can verify what will be removed. Captured calls can be deleted in two ways. “Delete filtered” removes calls matching the current URL and resource-type filters. “Delete selected” removes only explicitly selected calls. Deleting captured calls does not delete the associated website and does not delete mock rules. This allows users to clean up noisy or obsolete traffic without losing their testing configuration. ## Creating Mock Rules A mock rule defines when a request should be intercepted and what response should be returned. Rules belong to a specific monitored website, ensuring that a test configuration for one application does not unintentionally affect another application. A rule contains several key elements: - Enabled or disabled state - HTTP method - Match type - Match value - Response status - Response headers - Response body - Creation timestamp - Last-update timestamp The HTTP method can be a specific method such as `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `OPTIONS`, or `HEAD`. A rule can also use an empty method value to apply to any HTTP method. The match type can be Exact URL or Regex. An Exact URL rule matches the complete outgoing URL. This is the most precise option and is appropriate when a test should affect one known endpoint and one exact query or path combination. A Regex rule matches the URL using a regular expression. This is useful when several URLs share a pattern, when identifiers vary between requests, or when a tester wants one rule to cover a group of related endpoints. Invalid regular expressions are rejected during validation rather than being silently saved as unusable rules. When a rule is created from a captured call, V4 Prathirupa pre-populates the form with the original method, exact URL, response status, response headers, and response body. The tester can then edit the values before saving. The response status must be a valid HTTP status code between 100 and 599. Response headers are entered as a JSON object, and every header value must be a string. When the response content type indicates JSON or JSON-LD, the response body is validated as JSON before the rule can be saved. These checks catch common configuration mistakes before they affect the page under test. The rule editor supports creating a rule, editing an existing rule, and copying an existing rule into a new draft. Copying is useful when several scenarios share the same endpoint but differ in response status, headers, or body. A rule can be saved enabled or disabled. Saving it disabled allows a tester to prepare a scenario without activating it immediately. Saving it enabled makes it available for interception as soon as the relevant website and global state permit mocking. ## Mock Rule Matching The matching engine applies deterministic priority rules when more than one saved rule could match an outgoing request. First, enabled Exact URL rules are evaluated. If one or more exact matches are found, the most recently created or edited matching rule wins. If no exact match is available, enabled Regex rules are evaluated. Again, the most recently created or edited matching rule wins within the regex tier. If neither tier produces a match, the request is not replaced by V4 Prathirupa and proceeds normally. HTTP method matching is applied as part of the rule evaluation. A rule with a specific method only matches requests using that method. A rule configured for any method can match requests regardless of their method. This priority model makes precise rules take precedence over broad patterns. A tester can create a general regex rule for a family of endpoints and then add a specific exact-URL rule for one exceptional endpoint. The exact rule will win for that endpoint without requiring the broader rule to be removed. The extension checks for conflicting enabled rules when a rule is saved. A conflict has the same website, method, match type, and match value, preventing a rule that can never be selected from appearing active. ## Saved Mock Rules View The Saved Mock Rules view provides an overview of all rules belonging to the selected website. It is intended for ongoing scenario management after the initial capture-to-rule workflow is complete. Users can search rules by rule name or match type, filter by HTTP method, and choose between exact URL and regex rules. Each rule can be opened, copied, enabled, disabled, or deleted. Bulk selection is supported for rule management. Selected rules can be enabled together, disabled together, or permanently deleted after confirmation. Disabling a rule preserves its configuration for later reuse, while deleting it removes the rule entirely. An enabled rule does not automatically guarantee that every request will be mocked. It must also belong to an active, available website and the extension's global state must be active. The website itself must be enabled, and the request must satisfy the rule's method and URL matching conditions. ## Summary V4 Prathirupa provides a focused browser-based environment for understanding and controlling web API behavior. It combines explicit website authorization, per-site recording controls, detailed request inspection, locally persisted traffic history, configurable response rules, exact and regex matching, validation, bulk management, and a global pause mechanism. Its central workflow is simple: 1. Add and authorize a website. 2. Start recording for that website. 3. Use the application and capture real traffic. 4. Inspect requests, headers, payloads, responses, and timing. 5. Convert a captured call into a mock rule. 6. Customize the response status, headers, and body. 7. Enable the rule and repeat the application workflow. 8. Verify how the frontend responds to the controlled scenario. By keeping observation and mocking close to the browser, V4 Prathirupa helps teams test real application behavior with less setup and greater repeatability. It is especially useful for frontend resilience testing, API error simulation, exploratory debugging, regression preparation, and creating reusable local response scenarios without changing the application source code or backend service.