--- title: Davide's Code and Architecture Notes - Postel's law for... description: Explains Postel's law (the robustness principle), originally defined for TCP, as applied to Web API design: be conservative in what you send (don't change... canonical: https://daily.dev/posts/davide-s-code-and-architecture-notes---postel-s-law-for-api-robustness-hiyjjwadr twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Davide's Code and Architecture Notes - Postel's law for API Robustness | daily.dev og:description: Explains Postel's law (the robustness principle), originally defined for TCP, as applied to Web API design: be conservative in what you send (don't change... og:url: https://daily.dev/posts/davide-s-code-and-architecture-notes---postel-s-law-for-api-robustness-hiyjjwadr og:image: https://api.daily.dev/og/posts/HIYJjWaDr.png og:image:alt: Davide's Code and Architecture Notes - Postel's law for API Robustness og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Davide's Code and Architecture Notes - Postel's law for API Robustness **[Code4IT](https://daily.dev/sources/code4it)** · 6 min read · 0 upvotes · 0 comments ## Summary Explains Postel's law (the robustness principle), originally defined for TCP, as applied to Web API design: be conservative in what you send (don't change existing property names/types, minimize exposed fields) and be liberal in what you accept (ignore unsupported parameters, validate input, coerce data types). Also covers strategies for evolving APIs without breaking clients, including feature flags, versioning, deprecation instead of removal, and clear communication. Links to the original RFC 761 and further reading on robustness. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What does Postel's law mean when applied to API design? Postel's law, reworded for APIs, means be conservative in what you send and liberal in what you accept. Conservative sending means never changing the names or types of existing response properties and exposing only necessary fields to limit regression risk. Liberal accepting means ignoring unrecognized query parameters, headers, or body fields while still validating input and converting compatible data types like a numeric year sent as a string. _daily.dev surfaces API design principles like this for developers hardening service contracts against breaking changes._ ### How can I evolve an API without breaking existing clients? Use feature flags to develop and test new functionality before releasing it to a subset of users, maintain clear API versioning so clients know which features are available in each version, and deprecate endpoints or parameters instead of removing them outright, giving consumers advance notice before a future removal. _Teams planning API changes track strategies like deprecation and versioning on daily.dev before clients get caught out._ ## Similar posts on daily.dev - [You can refactor everything except your API](https://daily.dev/posts/you-can-refactor-everything-except-your-api-pcwpvakuq) · The Polymathic Engineer · 15 upvotes · 1 comments - [The 20 Software Engineering Laws](https://daily.dev/posts/the-20-software-engineering-laws-owj1euvui) · Tech World With Milan · 72 upvotes · 7 comments - [The Architecture of Resilience: From Robust Code to a Balanced Life](https://daily.dev/posts/the-architecture-of-resilience-from-robust-code-to-a-balanced-life-9ilvotcrl) · We Are .NET · 1 upvotes · 0 comments - [Navigating Backward and Forward Compatibility for Seamless CI/CD](https://daily.dev/posts/navigating-backward-and-forward-compatibility-for-seamless-ci-cd-eq7hafmoq) · AT&T Israel · 2 upvotes · 1 comments - [EP226: API Concepts Every Software Engineer Should Know](https://daily.dev/posts/ep226-api-concepts-every-software-engineer-should-know-rh6pqv5zh) · ByteByteGo · 15 upvotes · 1 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#backend](https://daily.dev/tags/backend) [View this post on daily.dev](https://daily.dev/posts/davide-s-code-and-architecture-notes---postel-s-law-for-api-robustness-hiyjjwadr) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Davide's Code and Architecture Notes - Postel's law for API Robustness","url":"https://daily.dev/posts/davide-s-code-and-architecture-notes---postel-s-law-for-api-robustness-hiyjjwadr","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/davide-s-code-and-architecture-notes---postel-s-law-for-api-robustness-hiyjjwadr"},"datePublished":"2026-10-04T13:07:11.351Z","dateModified":"2026-10-04T13:18:17.669Z","description":"Explains Postel's law (the robustness principle), originally defined for TCP, as applied to Web API design: be conservative in what you send (don't change...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/087f5659578658a57f744ba378c1e29e?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/087f5659578658a57f744ba378c1e29e?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Code4IT","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Code4IT","logo":"https://media.daily.dev/image/upload/s--OaaG4G10--/f_auto,q_auto/v1791119049/logos/code4it?_a=BAMAMicg0","url":"https://daily.dev/sources/code4it"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/davide-s-code-and-architecture-notes---postel-s-law-for-api-robustness-hiyjjwadr","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"architecture,backend","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Code4IT","item":"https://daily.dev/sources/code4it"},{"@type":"ListItem","position":3,"name":"Davide's Code and Architecture Notes - Postel's law for API Robustness"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/davide-s-code-and-architecture-notes---postel-s-law-for-api-robustness-hiyjjwadr#faq","mainEntity":[{"@type":"Question","name":"What does Postel's law mean when applied to API design?","acceptedAnswer":{"@type":"Answer","text":"Postel's law, reworded for APIs, means be conservative in what you send and liberal in what you accept. Conservative sending means never changing the names or types of existing response properties and exposing only necessary fields to limit regression risk. Liberal accepting means ignoring unrecognized query parameters, headers, or body fields while still validating input and converting compatible data types like a numeric year sent as a string. daily.dev surfaces API design principles like this for developers hardening service contracts against breaking changes."}},{"@type":"Question","name":"How can I evolve an API without breaking existing clients?","acceptedAnswer":{"@type":"Answer","text":"Use feature flags to develop and test new functionality before releasing it to a subset of users, maintain clear API versioning so clients know which features are available in each version, and deprecate endpoints or parameters instead of removing them outright, giving consumers advance notice before a future removal. Teams planning API changes track strategies like deprecation and versioning on daily.dev before clients get caught out."}}]} ```