Hello, world!
", 28 | "url": "https://example.org/initial-post" 29 | } 30 | ] 31 | } 32 | 33 | It supports more than just the above, of course. 34 | 35 | ## Goals 36 | 37 | After making feeds easier to read and write, our second goal is to provide a format that’s self-documenting and difficult to do wrong. 38 | 39 | We also want to support: 40 | 41 | * Microblogs, which are often plain text and without titles. So much web writing today is Twitter-like, which is actually plain text. 42 | * Multiple attachments. 43 | * Modern needs such as avatar images, feed icons and favicons, and banner and featured images. Feed readers should not have to search and scrape to guess at these things. 44 | * A simple way to add extensions. 45 | 46 | (Note about plain text: on this page it means “not HTML” — emojis, for instance, are considered plain text.) 47 | 48 | ## The Structure of a Feed 49 | 50 | A JSON Feed is a list that may change over time, and the individual items in the list may change. 51 | 52 | Think of a blog or microblog, Twitter or Facebook timeline, set of commits to a repository, or even a server log. These are all lists, and each could be described by a feed. 53 | 54 | A JSON Feed starts with some info at the top: it says where the feed comes from, and may say who created it and so on. 55 | 56 | After that there’s an array of objects — `items` — that describe each object in the list. 57 | 58 | ### Top-level 59 | 60 | * `version` (required, string) is the URL of the version of the format the feed uses. This should appear at the very top, though we recognize that not all JSON generators allow for ordering. 61 | 62 | * `title` (required, string) is the name of the feed, which will often correspond to the name of the website (blog, for instance), though not necessarily. 63 | 64 | * `home_page_url` (optional but strongly recommended, string) is the URL of the resource that the feed describes. This resource may or may not actually be a “home” page, but it should be an HTML page. If a feed is published on the public web, this should be considered as required. But it may not make sense in the case of a file created on a desktop computer, when that file is not shared or is shared only privately. 65 | 66 | * `feed_url` (optional but strongly recommended, string) is the URL of the feed, and serves as the unique identifier for the feed. As with `home_page_url`, this should be considered required for feeds on the public web. 67 | 68 | * `description` (optional, string) provides more detail, beyond the `title`, on what the feed is about. A feed reader may display this text. 69 | 70 | * `user_comment` (optional, string) is a description of the purpose of the feed. This is for the use of people looking at the raw JSON, and should be ignored by feed readers. 71 | 72 | * `next_url` (optional, string) is the URL of a feed that provides the next n items, where n is determined by the publisher. This allows for pagination, but with the expectation that reader software is not required to use it and probably won’t use it very often. `next_url` must not be the same as `feed_url`, and it must not be the same as a previous `next_url` (to avoid infinite loops). 73 | 74 | * `icon` (optional, string) is the URL of an image for the feed suitable to be used in a timeline, much the way an avatar might be used. It should be square and relatively large — such as 512 x 512 pixels — so that it can be scaled-down and so that it can look good on retina displays. It should use transparency where appropriate, since it may be rendered on a non-white background. 75 | 76 | * `favicon` (optional, string) is the URL of an image for the feed suitable to be used in a source list. It should be square and relatively small, but not smaller than 64 x 64 pixels (so that it can look good on retina displays). As with `icon`, this image should use transparency where appropriate, since it may be rendered on a non-white background. 77 | 78 | * `authors` (optional, array of objects) specifies one or more feed authors. The author object has several members. These are all optional — but if you provide an author object, then at least one is required: 79 | 80 | * `name` (optional, string) is the author’s name. 81 | 82 | * `url` (optional, string) is the URL of a site owned by the author. It could be a blog, micro-blog, Twitter account, and so on. Ideally the linked-to page provides a way to contact the author, but that’s not required. The URL could be a mailto: link, though we suspect that will be rare. 83 | 84 | * `avatar` (optional, string) is the URL for an image for the author. As with `icon`, it should be square and relatively large — such as 512 x 512 pixels — and should use transparency where appropriate, since it may be rendered on a non-white background. 85 | 86 | * `language` (optional, string) is the primary language for the feed in the format specified in [RFC 5646](https://tools.ietf.org/html/rfc5646). The value is usually a 2-letter language tag from [ISO 639-1](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes), optionally followed by a region tag. (Examples: `en` or `en-US`.) 87 | 88 | * `expired` (optional, boolean) says whether or not the feed is finished — that is, whether or not it will ever update again. A feed for a temporary event, such as an instance of the Olympics, could expire. If the value is `true`, then it’s expired. Any other value, or the absence of `expired`, means the feed may continue to update. 89 | 90 | * `hubs` (very optional, array of objects) describes endpoints that can be used to subscribe to real-time notifications from the publisher of this feed. Each object has a `type` and `url`, both of which are required. See the section “Subscribing to Real-time Notifications” below for details. 91 | 92 | ### Items 93 | 94 | `items` is an array, and is required. An item includes: 95 | 96 | * `id` (required, string) is unique for that item for that feed over time. If an item is ever updated, the `id` should be unchanged. New items should never use a previously-used `id`. Ideally, the `id` is the full URL of the resource described by the item, since URLs make great unique identifiers. 97 | 98 | * `url` (optional, string) is the URL of the resource described by the item. It’s the permalink. This may be the same as the `id` — but should be present regardless. 99 | 100 | * `external_url` (very optional, string) is the URL of a page elsewhere. This is especially useful for linkblogs. If `url` links to where you’re talking about a thing, then `external_url` links to the thing you’re talking about. 101 | 102 | * `title` (optional, string) is plain text. Microblog items in particular may omit titles. 103 | 104 | * `content_html` and `content_text` are each optional strings — but one or both must be present. This is the HTML or plain text of the item. Important: the only place HTML is allowed in this format is in `content_html`. A Twitter-like service might use `content_text`, while a blog might use `content_html`. Use whichever makes sense for your resource. (It doesn’t even have to be the same for each item in a feed.) 105 | 106 | * `summary` (optional, string) is a plain text sentence or two describing the item. This might be presented in a timeline, for instance, where a detail view would display all of `content_html` or `content_text`. 107 | 108 | * `image` (optional, string) is the URL of the main image for the item. This image may also appear in the `content_html` — if so, it’s a hint to the feed reader that this is the main, featured image. Feed readers may use the image as a preview (probably resized as a thumbnail and placed in a timeline). 109 | 110 | * `banner_image` (optional, string) is the URL of an image to use as a banner. Some blogging systems (such as [Medium](https://medium.com/)) display a different banner image chosen to go with each post, but that image wouldn’t otherwise appear in the `content_html`. A feed reader with a detail view may choose to show this banner image at the top of the detail view, possibly with the title overlaid. 111 | 112 | * `date_published` (optional, string) specifies the date in [RFC 3339](https://tools.ietf.org/html/rfc3339) format. (Example: `2010-02-07T14:04:00-05:00`.) 113 | 114 | * `date_modified` (optional, string) specifies the modification date in RFC 3339 format. 115 | 116 | * `authors` (optional, array of objects) has the same structure as the top-level `authors`. If not specified in an item, then the top-level `authors`, if present, are the authors of the item. 117 | 118 | * `tags` (optional, array of strings) can have any plain text values you want. Tags tend to be just one word, but they may be anything. Note: they are not the equivalent of Twitter hashtags. Some blogging systems and other feed formats call these categories. 119 | 120 | * `language` (optional, string) is the language for this item, using the same format as the top-level `language` field. The value can be different than the primary language for the feed when a specific item is written in a different language than other items in the feed. 121 | 122 | #### Attachments 123 | 124 | An individual item may have one or more attachments. 125 | 126 | * `attachments` (optional, array) lists related resources. Podcasts, for instance, would include an attachment that’s an audio or video file. Each attachment has several members: 127 | 128 | * `url` (required, string) specifies the location of the attachment. 129 | 130 | * `mime_type` (required, string) specifies the type of the attachment, such as “audio/mpeg.” 131 | 132 | * `title` (optional, string) is a name for the attachment. Important: if there are multiple attachments, and two or more have the exact same `title` (when `title` is present), then they are considered as alternate representations of the same thing. In this way a podcaster, for instance, might provide an audio recording in different formats. 133 | 134 | * `size_in_bytes` (optional, number) specifies how large the file is. 135 | 136 | * `duration_in_seconds` (optional, number) specifies how long it takes to listen to or watch, when played at normal speed. 137 | 138 | ### Deprecations 139 | 140 | JSON Feed version 1 specified a singular `author` field instead of the `authors` array used in version 1.1. New feeds should use `authors`, even if only 1 author is needed. Existing feeds can include both `author` and `authors` for compatibility with existing feed readers. Feed readers should always prefer `authors` if present. 141 | 142 | Deprecated items remain valid forever, but you should move to the new fields when you can. A feed using fields from JSON Feed 1.0 is still a valid feed for version 1.1 and future versions of JSON Feed. 143 | 144 | ## Extensions 145 | 146 | Publishers can use custom objects in JSON Feeds. Names must start with an `_` character followed by a letter. Custom objects can appear anywhere in a feed. 147 | 148 | For instance, imagine a podcast directory service — call it Blue Shed Podcasts — that asks a podcaster to specify some additional information about a feed or item. A publisher would do something like this: 149 | 150 | "_blue_shed": { 151 | "about": "https://blueshed-podcasts.com/json-feed-extension-docs", 152 | "explicit": false, 153 | "copyright": "1948 by George Orwell", 154 | "owner": "Big Brother and the Holding Company", 155 | "subtitle": "All shouting, all the time. Double. Plus. Good." 156 | } 157 | 158 | Feed readers that do not understand a given custom object must ignore it. 159 | 160 | The `about` string is there for a human looking at the feed, so they can understand what goes in the custom extension. It’s optional, but it should appear at least once in a feed that may contain multiple uses of `_blue_shed` (preferably in the first use, but that’s not required). 161 | 162 | Also, it’s good practice to name an extension with a company or service name, to provide a clue right away as to what it’s for and who made it. 163 | 164 | Further naming rules: the extension name and its member keys must not contain any `.` characters. The extension name, and only the extension name, must begin with an `_` character. (No standard keys will ever begin with an `_` — this is reserved for extensions.) 165 | 166 | Member keys should be alphanumeric. That said, emojis are not illegal — we’re not heartless — and somebody’s going to use them. 167 | 168 | ## Subscribing to Real-time Notifications 169 | 170 | Traditional feed readers usually poll a web site for changes at a regular interval. This is fine for many applications, but there’s a more efficient approach for applications that need to know the moment a feed changes. The top-level `hubs` array points to one or more services that can be used by feed aggregators to subscribe to changes to this feed. Those hubs can then send a notification to the application as soon as the feed is updated. 171 | 172 | The `type` field describes the protocol used to talk with the hub, such as “rssCloud” or “WebSub.” When using WebSub, the value for the JSON Feed’s `feed_url` is passed for the `hub.topic` parameter. For more information about WebSub, see [the specification at the W3C](https://www.w3.org/TR/websub/). 173 | 174 | ## Future Compatibility 175 | 176 | A version 1 feed will be a valid version 2 feed, and so on. Future versions may add things, but won’t make older feeds invalid. 177 | 178 | ### Key Naming Rules 179 | 180 | In future versions, defined keys will always adhere to these rules: 181 | 182 | * Leading `_` characters are reserved for extensions. 183 | * Keys will be made of alphanumeric characters from the ASCII character set. 184 | * Keys will never contain a `.` character. 185 | 186 | ## Suggestions for Publishers 187 | 188 | JSON Feed files should be served using the MIME type `application/feed+json`. Many feeds will still use the more general MIME type `application/json`, which is common wherever JSON is served. When discovering a feed, apps must prefer `application/feed+json`, but should fall back to accepting `application/json` if no feeds using `application/feed+json` are available. 189 | 190 | The number of items in a feed is unlimited, but practical limits should be observed. A 1MB feed places a burden on feed readers, especially if there are many such feeds. Under 100K is ideal, and 250K is fine. Use your judgment. If you need to provide older items, consider using pagination and `next_url`. 191 | 192 | Publishers should support [Conditional GET](https://fishbowl.pastiche.org/2002/10/21/http_conditional_get_for_rss_hackers/), to limit impact on their system when feed readers poll for changes. 193 | 194 | Also, to further reduce bandwidth use, publishers should provide the top-level `icon` and `favicon` URLs. When not present, feed readers will often attempt to find these things by 1) downloading the home page and scraping the HTML, and 2) making one or more requests to likely locations for these images. To reduce traffic on your server, put this info in the feed. 195 | 196 | JSON Feeds should be encoded using UTF-8 — but any encoding that’s [legal JSON](https://tools.ietf.org/html/rfc7159) is legal for JSON Feeds. 197 | 198 | Any publisher already publishing RSS and/or Atom should continue to do so. In fact, if you’re trying to decide which format (of RSS, Atom, and JSON Feed) to use, and you can do only one, pick RSS — it’s time-tested, popular, and good. 199 | 200 | ## Suggestions for Feed Readers 201 | 202 | If a feed is invalid JSON, then we strongly recommend not attempting to parse it or use partial data. You can’t rely on it. 203 | 204 | There are cases, though, where a required element might not be present. In the case of an `attachment` missing a `mime_type`, you can probably deal with it fine. After all, when you download the attached file, the web browser will provide a MIME type. (And you might have been able to guess it from the file suffix.) 205 | 206 | Another case might be a malformed `date_published` that you can’t parse. You might substitute the date the reader parsed it. (Feed readers have been doing that kind of thing for many years, for bad or missing dates.) 207 | 208 | As much as we’d like to encourage good feeds, we also emphasize that this is a pragmatic format, and the final test is user experience: if an error can be recovered from without significantly harming that experience, then it’s better than just refusing to use the feed (or part of the feed) at all. 209 | 210 | That said, there is one thing we insist on: any `item` without an `id` must be discarded. We come to this from years of experience dealing with feeds in other formats where unique identifiers are optional. Without unique identifiers, it’s impossible to reliably refer to a given `item` and its changes over time, and this is terrible for user experience and becomes a source of bug reports to you. (Your users will complain of “reruns.”) In that case, you may wish to alert the user that there’s a problem with the feed, and you may also wish to contact the publisher. 211 | 212 | If an `id` is presented as a number, a JSON Feed reader should coerce it to a string. If an `id` is blank or can't be coerced to a valid string, the `item` must be discarded. 213 | 214 | For web-based feed readers, it would be helpful to publishers if you reported your subscription numbers. To do this, add a substring of the form `(n subscribers)`, where n is the actual number, to the user-agent header in your http and https requests. 215 | 216 | Feed readers are strongly advised to use [Conditional GET](https://fishbowl.pastiche.org/2002/10/21/http_conditional_get_for_rss_hackers/), in order to minimize bandwidth and CPU cycles on clients and servers. 217 | 218 | On the issue of which URL to use — `url` or `external_url` — when opening a web page: because an item’s `url` is always a permalink, the `url` should be the default. For linkblogs that include an `external_url`, feed readers may give users a choice which URL to open: perhaps by displaying the `external_url` prominently in the UI, perhaps by a preference to use these URLs when present, or by some other mechanism. 219 | 220 | ### Discovery 221 | 222 | A web page should include a `link` tag that specifies the location of the JSON Feed. Like this: 223 | 224 | 225 | 226 | This is the same as the feed discovery mechanism used for RSS and Atom. 227 | 228 | The `title` attribute is optional, but can be useful to differentiate multiple feeds — for instance, there might be a feed for all blog posts and a feed for comments on a specific post. These should have different titles. 229 | 230 | In an ideal world, manual discovery — by a human using a web browser — is also possible, by adding `feed.json` to the resource the feed describes. If there’s a blog at `https://example.org/`, then a human could tryhttps://example.org/feed.json to find the feed.
231 |
232 | However, we realize that there are reasons — both technical and matters of preference — that prevent this from being universal, which is fine. But still, if you can do this, it would be nice.
233 |
234 | ### Linking to a Feed on a Web Page
235 |
236 | Publishers are encouraged to provide a link to their JSON Feed — as they do with RSS and Atom feeds — on their websites. It’s okay to make the link text “JSON Feed,” but a more specific title is also okay.
237 |
238 | You can also use the JSON Feed icon as a link on your site, like this:
239 |
240 | Hello, world!
", 28 | "url": "https://example.org/initial-post" 29 | } 30 | ] 31 | } 32 | 33 | It supports more than just the above, of course. 34 | 35 | ## Goals 36 | 37 | After making feeds easier to read and write, our second goal is to provide a format that’s self-documenting and difficult to do wrong. 38 | 39 | We also want to support: 40 | 41 | * Microblogs, which are often plain text and without titles. So much web writing today is Twitter-like, which is actually plain text. 42 | * Multiple attachments. 43 | * Modern needs such as avatar images, feed icons and favicons, and banner and featured images. Feed readers should not have to search and scrape to guess at these things. 44 | * A simple way to add extensions. 45 | 46 | (Note about plain text: on this page it means “not HTML” — emojis, for instance, are considered plain text.) 47 | 48 | ## The Structure of a Feed 49 | 50 | A JSON Feed is a list that may change over time, and the individual items in the list may change. 51 | 52 | Think of a blog or microblog, Twitter or Facebook timeline, set of commits to a repository, or even a server log. These are all lists, and each could be described by a feed. 53 | 54 | A JSON Feed starts with some info at the top: it says where the feed comes from, and may say who created it and so on. 55 | 56 | After that there’s an array of objects — `items` — that describe each object in the list. 57 | 58 | ### Top-level 59 | 60 | * `version` (required, string) is the URL of the version of the format the feed uses. This should appear at the very top, though we recognize that not all JSON generators allow for ordering. 61 | 62 | * `title` (required, string) is the name of the feed, which will often correspond to the name of the website (blog, for instance), though not necessarily. 63 | 64 | * `home_page_url` (optional but strongly recommended, string) is the URL of the resource that the feed describes. This resource may or may not actually be a “home” page, but it should be an HTML page. If a feed is published on the public web, this should be considered as required. But it may not make sense in the case of a file created on a desktop computer, when that file is not shared or is shared only privately. 65 | 66 | * `feed_url` (optional but strongly recommended, string) is the URL of the feed, and serves as the unique identifier for the feed. As with `home_page_url`, this should be considered required for feeds on the public web. 67 | 68 | * `description` (optional, string) provides more detail, beyond the `title`, on what the feed is about. A feed reader may display this text. 69 | 70 | * `user_comment` (optional, string) is a description of the purpose of the feed. This is for the use of people looking at the raw JSON, and should be ignored by feed readers. 71 | 72 | * `next_url` (optional, string) is the URL of a feed that provides the next n items, where n is determined by the publisher. This allows for pagination, but with the expectation that reader software is not required to use it and probably won’t use it very often. `next_url` must not be the same as `feed_url`, and it must not be the same as a previous `next_url` (to avoid infinite loops). 73 | 74 | * `icon` (optional, string) is the URL of an image for the feed suitable to be used in a timeline, much the way an avatar might be used. It should be square and relatively large — such as 512 x 512 — so that it can be scaled-down and so that it can look good on retina displays. It should use transparency where appropriate, since it may be rendered on a non-white background. 75 | 76 | * `favicon` (optional, string) is the URL of an image for the feed suitable to be used in a source list. It should be square and relatively small, but not smaller than 64 x 64 (so that it can look good on retina displays). As with `icon`, this image should use transparency where appropriate, since it may be rendered on a non-white background. 77 | 78 | * `author` (optional, object) specifies the feed author. The author object has several members. These are all optional — but if you provide an author object, then at least one is required: 79 | 80 | * `name` (optional, string) is the author’s name. 81 | 82 | * `url` (optional, string) is the URL of a site owned by the author. It could be a blog, micro-blog, Twitter account, and so on. Ideally the linked-to page provides a way to contact the author, but that’s not required. The URL could be a mailto: link, though we suspect that will be rare. 83 | 84 | * `avatar` (optional, string) is the URL for an image for the author. As with `icon`, it should be square and relatively large — such as 512 x 512 — and should use transparency where appropriate, since it may be rendered on a non-white background. 85 | 86 | * `expired` (optional, boolean) says whether or not the feed is finished — that is, whether or not it will ever update again. A feed for a temporary event, such as an instance of the Olympics, could expire. If the value is `true`, then it’s expired. Any other value, or the absence of `expired`, means the feed may continue to update. 87 | 88 | * `hubs` (very optional, array of objects) describes endpoints that can be used to subscribe to real-time notifications from the publisher of this feed. Each object has a `type` and `url`, both of which are required. See the section “Subscribing to Real-time Notifications” below for details. 89 | 90 | ### Items 91 | 92 | `items` is an array, and is required. An item includes: 93 | 94 | * `id` (required, string) is unique for that item for that feed over time. If an item is ever updated, the `id` should be unchanged. New items should never use a previously-used `id`. If an `id` is presented as a number or other type, a JSON Feed reader must coerce it to a string. Ideally, the `id` is the full URL of the resource described by the item, since URLs make great unique identifiers. 95 | 96 | * `url` (optional, string) is the URL of the resource described by the item. It’s the permalink. This may be the same as the `id` — but should be present regardless. 97 | 98 | * `external_url` (very optional, string) is the URL of a page elsewhere. This is especially useful for linkblogs. If `url` links to where you’re talking about a thing, then `external_url` links to the thing you’re talking about. 99 | 100 | * `title` (optional, string) is plain text. Microblog items in particular may omit titles. 101 | 102 | * `content_html` and `content_text` are each optional strings — but one or both must be present. This is the HTML or plain text of the item. Important: the only place HTML is allowed in this format is in `content_html`. A Twitter-like service might use `content_text`, while a blog might use `content_html`. Use whichever makes sense for your resource. (It doesn’t even have to be the same for each item in a feed.) 103 | 104 | * `summary` (optional, string) is a plain text sentence or two describing the item. This might be presented in a timeline, for instance, where a detail view would display all of `content_html` or `content_text`. 105 | 106 | * `image` (optional, string) is the URL of the main image for the item. This image may also appear in the `content_html` — if so, it’s a hint to the feed reader that this is the main, featured image. Feed readers may use the image as a preview (probably resized as a thumbnail and placed in a timeline). 107 | 108 | * `banner_image` (optional, string) is the URL of an image to use as a banner. Some blogging systems (such as [Medium](https://medium.com/)) display a different banner image chosen to go with each post, but that image wouldn’t otherwise appear in the `content_html`. A feed reader with a detail view may choose to show this banner image at the top of the detail view, possibly with the title overlaid. 109 | 110 | * `date_published` (optional, string) specifies the date in [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) format. (Example: `2010-02-07T14:04:00-05:00`.) 111 | 112 | * `date_modified` (optional, string) specifies the modification date in RFC 3339 format. 113 | 114 | * `author` (optional, object) has the same structure as the top-level `author`. If not specified in an item, then the top-level `author`, if present, is the author of the item. 115 | 116 | * `tags` (optional, array of strings) can have any plain text values you want. Tags tend to be just one word, but they may be anything. Note: they are not the equivalent of Twitter hashtags. Some blogging systems and other feed formats call these categories. 117 | 118 | #### Attachments 119 | 120 | An individual item may have one or more attachments. 121 | 122 | * `attachments` (optional, array) lists related resources. Podcasts, for instance, would include an attachment that’s an audio or video file. Each attachment has several members: 123 | 124 | * `url` (required, string) specifies the location of the attachment. 125 | 126 | * `mime_type` (required, string) specifies the type of the attachment, such as “audio/mpeg.” 127 | 128 | * `title` (optional, string) is a name for the attachment. Important: if there are multiple attachments, and two or more have the exact same `title` (when `title` is present), then they are considered as alternate representations of the same thing. In this way a podcaster, for instance, might provide an audio recording in different formats. 129 | 130 | * `size_in_bytes` (optional, number) specifies how large the file is. 131 | 132 | * `duration_in_seconds` (optional, number) specifies how long it takes to listen to or watch, when played at normal speed. 133 | 134 | ## Extensions 135 | 136 | Publishers can use custom objects in JSON Feeds. Names must start with an `_` character followed by a letter. Custom objects can appear anywhere in a feed. 137 | 138 | For instance, imagine a podcast directory service — call it Blue Shed Podcasts — that asks a podcaster to specify some additional information about a feed or item. A publisher would do something like this: 139 | 140 | "_blue_shed": { 141 | "about": "https://blueshed-podcasts.com/json-feed-extension-docs", 142 | "explicit": false, 143 | "copyright": "1948 by George Orwell", 144 | "owner": "Big Brother and the Holding Company", 145 | "subtitle": "All shouting, all the time. Double. Plus. Good." 146 | } 147 | 148 | Feed readers that do not understand a given custom object must ignore it. 149 | 150 | The `about` string is there for a human looking at the feed, so they can understand what goes in the custom extension. It’s optional, but it should appear at least once in a feed that may contain multiple uses of `_blue_shed` (preferably in the first use, but that’s not required). 151 | 152 | Also, it’s good practice to name an extension with a company or service name, to provide a clue right away as to what it’s for and who made it. 153 | 154 | Further naming rules: the extension name and its member keys must not contain any `.` characters. The extension name, and only the extension name, must begin with an `_` character. (No standard keys will ever begin with an `_` — this is reserved for extensions.) 155 | 156 | Member keys should be alphanumeric. That said, emojis are not illegal — we’re not heartless — and somebody’s going to use them. 157 | 158 | ## Subscribing to Real-time Notifications 159 | 160 | Traditional feed readers usually poll a web site for changes at a regular interval. This is fine for many applications, but there’s a more efficient approach for applications that need to know the moment a feed changes. The top-level `hubs` array points to one or more services that can be used by feed aggregators to subscribe to changes to this feed. Those hubs can then send a notification to the application as soon as the feed is updated. 161 | 162 | The `type` field describes the protocol used to talk with the hub, such as “rssCloud” or “WebSub.” When using WebSub, the value for the JSON Feed’s `feed_url` is passed for the `hub.topic` parameter. For more information about WebSub, see [the specification at the W3C](https://www.w3.org/TR/websub/). 163 | 164 | ## Future Compatibility 165 | 166 | A version 1 feed will be a valid version 2 feed, and so on. Future versions may add things, but won’t make older feeds invalid. 167 | 168 | ### Key Naming Rules 169 | 170 | In future versions, defined keys will always adhere to these rules: 171 | 172 | * Leading `_` characters are reserved for extensions. 173 | * Keys will be made of alphanumeric characters from the ASCII character set. 174 | * Keys will never contain a `.` character. 175 | 176 | ## Suggestions for Publishers 177 | 178 | JSON Feed files must be served using the same MIME type — `application/json` — that’s used whenever JSON is served. 179 | 180 | The number of items in a feed is unlimited, but practical limits should be observed. A 1MB feed places a burden on feed readers, especially if there are many such feeds. Under 100K is ideal, and 250K is fine. Use your judgment. If you need to provide older items, consider using pagination and `next_url`. 181 | 182 | Publishers should support [Conditional GET](https://fishbowl.pastiche.org/2002/10/21/http_conditional_get_for_rss_hackers/), to limit impact on their system when feed readers poll for changes. 183 | 184 | Also, to further reduce bandwidth use, publishers should provide the top-level `icon` and `favicon` URLs. When not present, feed readers will often attempt to find these things by 1) downloading the home page and scraping the HTML, and 2) making one or more requests to likely locations for these images. To reduce traffic on your server, put this info in the feed. 185 | 186 | JSON Feeds should be encoded using UTF-8 — but any encoding that’s [legal JSON](https://www.ietf.org/rfc/rfc4627.txt) is legal for JSON Feeds. 187 | 188 | Any publisher already publishing RSS and/or Atom should continue to do so. In fact, if you’re trying to decide which format (of RSS, Atom, and JSON Feed) to use, and you can do only one, pick RSS — it’s time-tested, popular, and good. 189 | 190 | ## Suggestions for Feed Readers 191 | 192 | If a feed is invalid JSON, then we strongly recommend not attempting to parse it or use partial data. You can’t rely on it. 193 | 194 | There are cases, though, where a required element might not be present. In the case of an `attachment` missing a `mime_type`, you can probably deal with it fine. After all, when you download the attached file, the web browser will provide a MIME type. (And you might have been able to guess it from the file suffix.) 195 | 196 | Another case might be a malformed `date_published` that you can’t parse. You might substitute the date the reader parsed it. (Feed readers have been doing that kind of thing for many years, for bad or missing dates.) 197 | 198 | As much as we’d like to encourage good feeds, we also emphasize that this is a pragmatic format, and the final test is user experience: if an error can be recovered from without significantly harming that experience, then it’s better than just refusing to use the feed (or part of the feed) at all. 199 | 200 | That said, there is one thing we insist on: any `item` without an `id` must be discarded. We come to this from years of experience dealing with feeds in other formats where unique identifiers are optional. Without unique identifiers, it’s impossible to reliably refer to a given `item` and its changes over time, and this is terrible for user experience and becomes a source of bug reports to you. (Your users will complain of “reruns.”) In that case, you may wish to alert the user that there’s a problem with the feed, and you may also wish to contact the publisher. 201 | 202 | For web-based feed readers, it would be helpful to publishers if you reported your subscription numbers. To do this, add a substring of the form `(n subscribers)`, where n is the actual number, to the user-agent header in your http and https requests. 203 | 204 | Feed readers are strongly advised to use [Conditional GET](https://fishbowl.pastiche.org/2002/10/21/http_conditional_get_for_rss_hackers/), in order to minimize bandwidth and CPU cycles on clients and servers. 205 | 206 | On the issue of which URL to use — `url` or `external_url` — when opening a web page: because an item’s `url` is always a permalink, the `url` should be the default. For linkblogs that include an `external_url`, feed readers may give users a choice which URL to open: perhaps by displaying the `external_url` prominently in the UI, perhaps by a preference to use these URLs when present, or by some other mechanism. 207 | 208 | ### Discovery 209 | 210 | A web page should include a `link` tag that specifies the location of the JSON Feed. Like this: 211 | 212 | 213 | 214 | This is the same as the feed discovery mechanism used for RSS and Atom. 215 | 216 | The `title` attribute is optional, but can be useful to differentiate multiple feeds — for instance, there might be a feed for all blog posts and a feed for comments on a specific post. These should have different titles. 217 | 218 | In an ideal world, manual discovery — by a human using a web browser — is also possible, by adding `feed.json` to the resource the feed describes. If there’s a blog at `https://example.org/`, then a human could tryhttps://example.org/feed.json to find the feed.
219 |
220 | However, we realize that there are reasons — both technical and matters of preference — that prevent this from being universal, which is fine. But still, if you can do this, it would be nice.
221 |
222 | ### Linking to a Feed on a Web Page
223 |
224 | Publishers are encouraged to provide a link to their JSON Feed — as they do with RSS and Atom feeds — on their websites. It’s okay to make the link text “JSON Feed,” but a more specific title is also okay.
225 |
226 | You can also use the JSON Feed icon as a link on your site, like this:
227 |
228 |
6 | Blog •
7 | Version 1.1
8 |
9 | Mapping RSS and Atom •
10 | Code
11 |
12 | GitHub Repo •
13 | JSON Feed •
14 | RSS Feed
15 |
18 | 20 | © 2017-2019 Brent Simmons and 21 | Manton Reece 22 |
23 |