Designing REST APIs your web and mobile clients will thank you for

An API is a product with its own users: the developers building against it. Treat it that way and the whole system gets easier to change.

Get the basics boringly consistent

• Nouns for resources, plural, lowercase — /invoices, /invoices/42/line-items.
• One pagination style everywhere (cursor for feeds, offset for admin tables) and document it once.
• One error envelope: an HTTP status, a stable machine code, a human message, and a details map for field errors.
• Dates in ISO 8601 UTC. Money as integer minor units plus a currency. Never floats.

Versioning

Put the version in the URL (/v1/). Add fields freely; never remove or repurpose one within a version. When you must break, ship /v2/ and run both for a deprecation window.

Make the happy path one call

If a screen needs a resource plus three related things, let the client ask for them with an include= parameter rather than making four round trips on a mobile network.

Auth that fits clients

Short-lived access tokens, a refresh mechanism, and scopes that map to real product permissions. Rate-limit per key and return the limit headers so clients can back off.