The TL;DR, is that these plugins exist to help developers work with existing systems that don’t play nicely with mobile apps, and so when devs ask which to use, I really recommend using mechanisms that are built with native apps in mind (ex, tokens from the OAuth spec instead of using cookies).
The more detailed answer focuses on two pain points that developers pretty consistently run into that are specific to our case.
- CORS - CORS can cause all sorts of issues, but in “true native” development, CORS doesn’t exist. This can cause problems for Capacitor devs because they can be working with services that don’t account for CORS. Capacitor HTTP exists so that HTTP traffic can be proxied through the native layer to bypass this CORS restriction that only exists because we’re running in a web browser. If CORS isn’t a problem (because servers are configured properly, or you’re only communicating with your own server, as some examples) you probably don’t need and shouldn’t enable Capacitor HTTP plugin. It’s just additional overhead and complexity that brings no benefit.
- Cookies - Many web services that developers want to use rely on cookies. Cookies are a standard part of the web, but they are pretty non-existent as a concept for native mobile apps. As such, trying to implement anything cookie related can cause weird and unexpected issues. The cookies plugin was built to help solve for those specific cases by managing cookies in “native land” and which also necessitates enabling and using Capacitor HTTP, so the native layer can add/receive cookies from requests. This means all your requests now go through native, which is more overhead, makes your http requests more difficult to debug, etc.
Enabling these plugins can fix certain problems that can be complete blockers for devs, but they also bring baggage with them. So if you’re in a position to choose what to use, I’d always suggest the simpler solutions that “just work” over using tools built for compatibility reasons.