microformats are extensions to HTML for marking up people, organizations, events, locations, blog posts, products, reviews, resumes, recipes etc. Sites use microformats to publish a standard API that is consumed and used by search engines, aggregators, and other tools.
You should publish the microformats that themselves have reasons why to use that resonate with you, e.g.:
The IndieWeb makes heavy use of:
- h-card to mark up profiles and authors in published posts, then consumed by code (e.g. reply-contexts, readers) for authorship and more.
- h-entry to markup posts, replies, etc., then consumed by code for displaying, summarizing, replying.
- in-reply-to to markup links from replies to original posts, then consumed by code for displaying comments, comment threads, etc.
- XFN for relationships, and identity consolidation (rel=me), consumed by code for IndieAuth etc.
There is a fuller list of implementations on the microformats wiki. Here are some used by the indieweb community:
- indiewebify me - a step by step markup guide and validator
- unmung - a feed to mf2 transalator, and an mf2 parser based on mf2py
- pin13.net - Aaron's PHP-based parser.
Are microformats an API
Q: Are microformats an API?
A: No, microformats are more like the information returned from an API.
HTTP GET of a particular URL of a website can be an API. microformats in the resulting HTML provide the information you might otherwise get from a bespoke API.
Thus combining HTTP, good site URL design, and microformats, your site can be your API. No separate XML/RDF/JSON/??? API endpoints needed. At least for readonly. For a write "API", see micropub.
A: Actually, yes, microformats are the simplest way of providing a read-only API, also known as "your website is your API".
Why not APIs
Q: Why not APIs instead of microformats?
A: See API, in short:
- secondary URLs
- secondary formats
- API key
- TOS requirements
- Unique snowflakes