{"id":29276,"date":"2024-06-24T12:50:00","date_gmt":"2024-06-24T11:50:00","guid":{"rendered":"https:\/\/www.web-systems.pl\/choosing-between-a-mobile-app-and-a-web-app\/"},"modified":"2024-06-24T12:50:00","modified_gmt":"2024-06-24T11:50:00","slug":"choosing-between-a-mobile-app-and-a-web-app","status":"publish","type":"post","link":"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/","title":{"rendered":"Step by step: choosing between a mobile app and a web app"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Mobile app or web app? A question as old as the iPhone, and the answer still is not obvious. At Web Systems we have been dealing with this since 2006 &#8211; we started out as a software house in \u0141\u00f3d\u017a and over almost two decades we have <a href=\"https:\/\/www.web-systems.pl\/en\/software-development\/\">delivered dozens of projects of both kinds<\/a>. And you know what? There is no single right answer. Every case is different. It depends on the budget, the target group, the schedule, the business needs. I wrote this guide on the basis of real rollouts, not textbook comparisons. I will show you how to approach this dilemma without shooting in the dark, because we regularly see clients who come to us after failed projects at the competition. And every time the problem started with a bad decision at the very beginning.<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Spis tre\u015bci<\/p>\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#What_actually_makes_a_mobile_app_different_from_a_web_app\" >What actually makes a mobile app different from a web app<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#When_a_web_app_is_the_better_choice\" >When a web app is the better choice<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#When_you_cannot_do_without_a_mobile_app\" >When you cannot do without a mobile app<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#Costs_delivery_time_and_the_hidden_risks_of_both_paths\" >Costs, delivery time and the hidden risks of both paths<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#The_hybrid_and_cross-platform_approach_%E2%80%93_is_the_compromise_worth_it\" >The hybrid and cross-platform approach &#8211; is the compromise worth it<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#How_to_approach_the_decision_%E2%80%93_a_practical_checklist\" >How to approach the decision &#8211; a practical checklist<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#FAQ\" >FAQ<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#Can_I_start_with_a_web_app_and_add_a_mobile_one_later\" >Can I start with a web app and add a mobile one later?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#How_much_does_it_cost_to_maintain_a_mobile_app_compared_with_a_web_app\" >How much does it cost to maintain a mobile app compared with a web app?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#Is_a_PWA_a_good_alternative_to_a_native_mobile_app\" >Is a PWA a good alternative to a native mobile app?<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/www.web-systems.pl\/en\/choosing-between-a-mobile-app-and-a-web-app\/#Summary\" >Summary<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"What_actually_makes_a_mobile_app_different_from_a_web_app\"><\/span>What actually makes a mobile app different from a web app<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A web app runs in the browser. No installation. It can be a classic website, a Single Page Application (SPA) reacting dynamically to clicks, or a Progressive Web App (PWA) with partial offline access and an icon on the home screen. A native mobile app is a completely different story &#8211; software written for iOS or Android, distributed through the App Store or Google Play. And that difference in the distribution channel changes everything. The browser versus the app store: two separate worlds with their own rules of the game.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Where do native apps win across the board? Access to hardware. GPS working in the background, a camera with full control over parameters, a biometric reader, motion sensors, push notifications &#8211; all of that works reliably only natively. The web is gradually catching up, sure. But it still does not match native solutions in terms of smoothness and the range of integration with the system.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Distribution<\/strong> &#8211; a web app is available instantly through a URL, a mobile one has to be downloaded from a store<\/li>\n<li><strong>Updates<\/strong> &#8211; a web app updates automatically, a mobile one requires downloading a new version (or a store review)<\/li>\n<li><strong>Performance<\/strong> &#8211; a native app makes full use of the device&#8217;s processor and GPU<\/li>\n<li><strong>Offline access<\/strong> &#8211; a native app works without a network, a PWA offers a limited offline mode<\/li>\n<li><strong>SEO<\/strong> &#8211; web apps get indexed in search engines, mobile ones stay invisible to Google<\/li>\n<li><strong>Entry costs<\/strong> &#8211; a web app is one project, a native one means separate rollouts on iOS and Android<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tip:<\/strong> A PWA will work as a replacement for a native mobile app when your product does not require advanced hardware access, offline work with large data sets or intensive graphics operations. If the main value lies in displaying content and simple interaction, a PWA will let you save up to 60% of the budget compared with the native approach.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"When_a_web_app_is_the_better_choice\"><\/span>When a web app is the better choice<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">From our experience, we build most B2B systems, admin panels, analytics dashboards and e-commerce platforms as web apps. Because the users of those tools sit at desks, work on large screens and want fast access without installing anything. An order management panel, a CRM, a sales reporting tool &#8211; all of that naturally fits the browser. Give someone a URL and you are done. No barrier to entry, and onboarding new people in the company takes minutes instead of hours.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">And then there are the costs. A web app is simply cheaper to build. You maintain one code base instead of two separate projects for iOS and Android. One team, one testing process, one deployment pipeline. The effect? A shorter time to market. And that can be decisive when you have to validate a business idea quickly. We regularly suggest that clients start with a web MVP before they put serious money into a native mobile app.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>&#8220;The most important principle is separation of concerns &#8211; dividing the application into methods, classes, files, packages, modules and layers with clearly defined scopes of responsibility and boundaries.&#8221;<\/p>\n<footer>&#8211; Android application architecture documentation, Google<\/footer>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">This principle works exactly the same in the web world. A well built SPA with separate layers for the UI, business logic and data access is far easier to maintain than monolithic code. React, Vue, Angular &#8211; these technologies let you build interfaces whose smoothness matches desktop applications. I have checked that many times in my own projects.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tip:<\/strong> Before you spend the budget on a native mobile app, validate your idea with a web MVP. Three months of collecting data on user behavior will tell you more than the best business plan. If 80% of the traffic comes from mobile devices, that is a clear signal that investing in a native experience is worth it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"When_you_cannot_do_without_a_mobile_app\"><\/span>When you cannot do without a mobile app<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">There are situations in which a web app simply will not do the job. Your product has to work offline, say an app for field technicians working in areas with no coverage? A native app with a local database is the only sensible option. The same goes for when you need the camera for real, motion sensors, Bluetooth Low Energy or geolocation in the background. The browser has its limits and no JavaScript library will get past them.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">But there is also the question of interface smoothness. Complex animations, multi-touch gestures, an instant reaction to every tap: here native apps simply crush the web. Games, fitness apps with real-time visualizations, photo editing tools. Every millisecond of delay means a worse user experience. And the user feels it, even if they cannot say why.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>&#8220;Mobile devices, even the ones with large screens, have limited resources, so at any moment the operating system can kill an application process in order to hand the resources over to other processes.&#8221;<\/p>\n<footer>&#8211; Android application architecture documentation, Google<\/footer>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">This limitation forces a well thought out architecture. Native SDKs give you tools for managing the application lifecycle, preserving state and restoring the session after the system has killed something. Web technologies? They do not have such precise control over these mechanisms. There is no point pretending otherwise.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Your users need offline functionality in environments without stable internet access<\/li>\n<li>The product makes heavy use of the camera, background GPS, the accelerometer or other sensors<\/li>\n<li>Push notifications are a key communication channel with your users<\/li>\n<li>You need integration with system features such as HealthKit, Google Fit or NFC payments<\/li>\n<li>Smooth animations and an instantly responsive interface decide user retention<\/li>\n<li>The business model assumes a presence in the App Store or Google Play as a customer acquisition channel<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Costs_delivery_time_and_the_hidden_risks_of_both_paths\"><\/span>Costs, delivery time and the hidden risks of both paths<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Comparing the costs of a web app and a mobile app only at the rollout stage? That is the most common mistake we see with clients. A simple web app costs from 50 to 150 thousand zloty. A native one for a single mobile platform costs from 100 to 250 thousand. For both? Almost double that amount. Cross-platform (Flutter, React Native) sits somewhere in between, saving 30-40% compared with two native rollouts. But those numbers are only the beginning.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The hidden costs of mobile apps can knock even experienced PMs off their feet. Apple and Google take a 15-30% commission on in-app transactions. The review process in the stores can delay the rollout of a critical hotfix by several days (and no, there is no way to speed it up). Every new version of iOS or Android means compatibility testing and potential code fixes. And the fragmentation of Android devices? Testing on dozens of resolutions, system versions and skins from Samsung, Xiaomi or Huawei. A nightmare.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When you look at this from the perspective of several years, the picture changes completely. Maintaining a mobile app on two platforms costs 15-25% of the value of the initial rollout per year. Library updates, adapting to new system versions, crash monitoring, reacting to changes in store guidelines: that is a constant stream of work that never ends. A web app generates lower maintenance costs, although it too requires regular dependency updates and the patching of security holes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Tip:<\/strong> When you build the project budget, add a 25-30% buffer for unforeseen expenses. Account for the cost of the first 12 months of maintenance before development work even starts. At Web Systems we always present clients with the TCO (Total Cost of Ownership) over 3 years, not just the cost of the rollout itself. Such a realistic financial picture makes it possible to avoid a situation in which there is no money left to maintain a working product.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"The_hybrid_and_cross-platform_approach_%E2%80%93_is_the_compromise_worth_it\"><\/span>The hybrid and cross-platform approach &#8211; is the compromise worth it<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Flutter, React Native, Kotlin Multiplatform &#8211; they all promise the same thing: write once, run on both platforms. And in many cases that promise holds. But not always. Cross-platform works great in apps with a standard UI, typical navigation and moderate use of hardware. Information apps, e-commerce platforms, task management tools: here you save time and budget without visible compromises on quality.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The problem starts with deep platform integration. Advanced ARKit on iOS, specific Material Design behavior on Android, non-standard UI components: in these places cross-platform generates technical debt. Workarounds, native bridges, platform-specific code. And suddenly the main advantage, a shared code base, goes out of the window. I have seen projects myself where 40% of the cross-platform code had to be written separately for each system anyway. And what is the point of that?<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The strategy we often suggest to clients is a two-stage approach. First we build a <a href=\"https:\/\/www.web-systems.pl\/en\/website-and-online-store-development\/\">solid web app<\/a>, responsive, fast, with a properly designed API. Then, once market data confirms that users really do want a native mobile experience, we extend the ecosystem with a dedicated app. The API is already there, the business logic has been tested, the team knows the domain. Minimal risk, and the money goes where it brings the biggest return.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Our experience with Flutter in medium-sized projects is positive, especially when the client needs to be on both mobile platforms but has a limited budget. React Native, in turn, works well in teams that are deep into JavaScript, because it lets them share knowledge between the web frontend and the mobile one. Which makes sense, all in all.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"How_to_approach_the_decision_%E2%80%93_a_practical_checklist\"><\/span>How to approach the decision &#8211; a practical checklist<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before you settle on a technology, answer a few questions about your product and your market honestly. With us every project starts with a discovery workshop: we sit down with the client and go through the decision matrix. We do not impose a solution. We gather data so that the decision is an informed one. Because far too often people come to us already convinced that they &#8220;have to have a mobile app&#8221;, while a responsive web app would handle the job just as well. Or better.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Who is your user?<\/strong> A professional at a desk or a person in the field using a smartphone?<\/li>\n<li><strong>Which hardware features are essential?<\/strong> Camera, background GPS, Bluetooth &#8211; does your product really need them?<\/li>\n<li><strong>What does the budget for the first 3 years look like?<\/strong> Include the rollout, maintenance, updates and further development<\/li>\n<li><strong>What is an acceptable time to market?<\/strong> Can you afford 6-9 months of developing a native app?<\/li>\n<li><strong>Is offline mode critical?<\/strong> Truly critical, not just &#8220;it would be nice to have&#8221;<\/li>\n<li><strong>What is the distribution strategy?<\/strong> SEO and organic traffic versus a presence in the app stores<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The decision matrix rests on four axes: the target group, the required features, the available budget and the acceptable delivery time. Is your target group corporate people on laptops? You do not need a native mobile app. Do the features require device sensors and can the budget carry 12 months of development? Then the native path makes sense. But most cases sit somewhere between these extremes. And the answer is usually a staged approach.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Prototyping and market validation before the final technology decision pay off many times over. A clickable prototype in Figma tested on a group of target users will reveal holes in your assumptions faster than months of coding. Who you work with matters just as much. Look for a technology partner who has done projects of both kinds and can advise objectively, without favoring the solution they happen to specialize in.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"FAQ\"><\/span>FAQ<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Can_I_start_with_a_web_app_and_add_a_mobile_one_later\"><\/span>Can I start with a web app and add a mobile one later?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Yes, and honestly, we often recommend it. The key is designing a solid API from the very beginning. A web app communicating with the backend through a REST API or GraphQL creates a foundation to which you can later attach a native mobile app without rewriting the server-side logic. It is important that the architecture assumes multi-channel access to data from day one. The cost of adding a mobile app in the second stage is lower, because the backend, the database and the business logic already exist and have passed the battle test in production.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"How_much_does_it_cost_to_maintain_a_mobile_app_compared_with_a_web_app\"><\/span>How much does it cost to maintain a mobile app compared with a web app?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The annual cost of maintaining a native mobile app on two platforms is usually 15-25% of the value of the original rollout. That includes updates for new versions of iOS and Android, stability monitoring, fixes for bugs reported by users and adapting to changing store guidelines. A web app is cheaper to maintain, usually 10-15% per year, because you no longer have to track changes in two mobile ecosystems and go through store reviews. The difference becomes substantial after a few years.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Is_a_PWA_a_good_alternative_to_a_native_mobile_app\"><\/span>Is a PWA a good alternative to a native mobile app?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">It depends on the project. A PWA works where the main value is presenting content, simple interaction with the user and basic offline functionality. News portals, product catalogs, simple business tools: in these cases a PWA gives you 80% of the native experience at 40% of the cost. A decent deal. The line runs where you need push notifications on iOS with full control, advanced hardware access or a presence in the stores as a marketing channel. Then there is no shortcut: a native solution is the only option.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Summary\"><\/span>Summary<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The choice between a mobile app and a web app should not depend on trends or personal preferences. It is a business decision. The user profile, the required features, the budget for rollout and maintenance, the acceptable time to market: these are the hard data it is worth basing it on. There is no universal solution. But an optimal one for your particular case? Absolutely.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The analysis of business needs should come first. Before any conversation about technology. Far too often we see the opposite order, with the client arriving with the wish &#8220;I want a mobile app&#8221; instead of with the business problem that the app is supposed to solve. A well run discovery workshop saves months of work and tens of thousands of zloty. Because it catches wrong assumptions before anyone writes the first line of code.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you are facing a decision about the technology for your digital product, let us talk. At Web Systems we have been helping companies get from an idea to a working solution since 2006, whether it turns out to be a web app, a mobile app or a hybrid one. Contact us to arrange a free technical consultation and work out together which path best matches your business goals.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Mobile app or web app? A question as old as the iPhone, and the answer still is not obvious. At Web Systems we have been dealing with this since 2006 &#8211; we started out as a software house in \u0141\u00f3d\u017a and over almost two decades we have delivered dozens of projects of both kinds. And [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":28132,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[832,830,806],"tags":[1290,1081,1292,863,1099,1112,1132,865],"class_list":["post-29276","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guides","category-mobile-apps","category-web-development-en","tag-android-en","tag-guide","tag-ios-en","tag-mobile-apps","tag-pwa-en","tag-software-development","tag-software-house-en","tag-web-applications"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/posts\/29276","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/comments?post=29276"}],"version-history":[{"count":0,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/posts\/29276\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/media\/28132"}],"wp:attachment":[{"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/media?parent=29276"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/categories?post=29276"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.web-systems.pl\/en\/wp-json\/wp\/v2\/tags?post=29276"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}