Content and Search
The Strapi API: REST & GraphQL
Lesson 2 of 5
What you'll learn
- Know what endpoints Strapi generates from a content type
- Read REST filter and populate query parameters
- Build a query string from a filter object
The moment you define a content type, Strapi generates a full API for it — no controllers to write. A collection type article gives you REST routes for list, read, create, update, and delete.
GET /api/articles # list
GET /api/articles/:id # read one
POST /api/articles # create
PUT /api/articles/:id # update
DELETE /api/articles/:id # delete
The same schema is also exposed over GraphQL when the GraphQL plugin is enabled, so a client can pick either style against one data model.
Filters and populate
By default a list response returns each entry's own fields but not its relations — those are omitted unless you ask for them with populate. You narrow results with filters, using operators like $contains, $eq, and $gt. Strapi encodes these as nested bracket query parameters:
GET /api/articles?filters[title][$contains]=strapi&populate=author
query {
articles(filters: { title: { contains: "strapi" } }) {
data { attributes { title author { data { attributes { name } } } } }
}
}
Populate is opt-in
Forgetting populate is the most common Strapi surprise: relations, media, and components come back empty unless you request them. Populate only what you need — populate=* pulls every relation and can be expensive.
The challenge models the REST encoding: turn a filter object and a populate list into the bracketed query string Strapi expects.
Run it. It flattens a filter object into filters[field][$op]=value pairs, appends populate, and joins them with &.
Next: we leave Strapi and open up the search engine — starting with the inverted index.
Sign in to save your progress across devices.