REST API vs SDK: Which Should Your App Use?

SDKs (Software Development Kits) are client libraries provided by services like Supabase, Firebase, and AWS. They wrap API calls in language-specific methods, handle authentication, manage state, and provide TypeScript types.

The appeal is obvious: supabase.from('users').select('*') is more readable than building a raw HTTP request. SDKs handle retries, caching, error parsing, and token refresh automatically.

But SDKs come with costs:

- Bundle size — The Firebase JS SDK adds 50-100KB+ to your bundle. Supabase's SDK is smaller but still a dependency. - Vendor lock-in — Every SDK call is a vendor-specific API call embedded in your code. The more SDK calls you have, the harder it is to switch providers. - Learning curve — Each SDK has its own patterns, types, and quirks. Switching providers means learning a new SDK. - Version management — SDK updates can introduce breaking changes. You're dependent on the vendor's release cycle. - Cross-platform consistency — An SDK's behavior may differ across web, iOS, and Android versions.

REST APIs use standard HTTP methods (GET, POST, PUT, DELETE) with JSON payloads. Every programming language and platform can make HTTP requests. There's nothing to install, no SDK to learn, no bundle size impact.

A REST API call is inherently portable: fetch('/api/db/users') works the same in React, Vue, Svelte, React Native, Flutter, Swift, Kotlin, Python, Go, and plain HTML. If you switch providers (but keep the same API shape), your frontend code doesn't change.

The trade-offs:

- More boilerplate — You handle request construction, error parsing, and token management yourself. - No type safety — Unless you generate types from an OpenAPI spec, you lose the TypeScript benefits of SDKs. - No automatic retries or caching — You implement these yourself or use a fetch wrapper like ky or ofetch.

There's a middle ground: use a unified REST API that's designed for developer experience. This is the approach ShipStack takes.

ShipStack exposes three clean endpoints — /api/auth, /api/db, /api/storage — with consistent request and response formats. You don't need an SDK because the API is simple enough to use with fetch(). But you also don't deal with raw provider APIs because ShipStack handles the translation.

The result: - No SDK dependency — Standard fetch() calls keep your bundle light and your code portable. - Zero vendor lock-in — The same API calls work regardless of which provider is behind them. - Cross-platform by default — One API for web, mobile, server, and IoT. - Consistent errors — ShipStack normalizes error responses across providers into a standard format.

For teams that want SDK-like convenience, ShipStack's API is designed to be wrapped in a thin client utility (50 lines of code) that provides type safety and convenience without vendor coupling.

SDKs are still the right choice in specific situations:

- You're deeply committed to one provider and have no plans to switch. - You need real-time features that the SDK handles (Firestore onSnapshot, Supabase realtime). - You're building a mobile app where offline persistence and background sync are critical. - The SDK provides significant functionality beyond API wrapping (analytics, crash reporting, performance monitoring).

In these cases, the SDK's convenience outweighs the lock-in cost.

REST APIs are the better choice when:

- You want provider flexibility and might switch in the future. - You're building for multiple platforms (web, mobile, server) and want one data layer. - Bundle size matters (SPAs, mobile web, edge-rendered pages). - You're an agency building for clients with different provider preferences. - You want your codebase to be simple — HTTP requests are universally understood, SDKs are not.

For most new projects in 2025, starting with a REST API (especially a unified one like ShipStack) gives you maximum flexibility with minimal overhead.