Skip to content

Render DFC collections in containers for v2 requests#14374

Open
mkllnk wants to merge 6 commits into
openfoodfoundation:masterfrom
mkllnk:dfc2-containers
Open

Render DFC collections in containers for v2 requests#14374
mkllnk wants to merge 6 commits into
openfoodfoundation:masterfrom
mkllnk:dfc2-containers

Conversation

@mkllnk

@mkllnk mkllnk commented Jun 5, 2026

Copy link
Copy Markdown
Member

ℹ️ Use Clockify code #13323 Connecting Farms and Markets while working on this.

What? Why?

⚠️ There are a couple of breaking changes for v1 in here. I don't think that they will impact real life scenarios but I may not be aware of all users of the DFC API.

With these changes, all endpoints will support rendering in DFC v2 format as JSON-LD. The data content is not migrated to the new models yet. Enterprises are not send as Organization yet (coming soon). But everything is sent with the newest context and using containers where required. LDP Containers are required in DFC v2 when publishing lists of resources like our index actions do.

What should we test?

  • @RachL, are you aware of any integrations that are active, supported and should be tested?

Release notes

Changelog Category (reviewers may add a label for the release notes):

  • User facing changes
  • API changes (V0, V1, DFC or Webhook)
  • Technical changes only
  • Feature toggled

The title of the pull request will be included in the release notes.

Dependencies

Documentation updates

mkllnk added 5 commits June 5, 2026 16:27
This is a breaking change because we remove the Person (current user)
from the response. Including relationships to the authenticated person
was an early concept of the DFC standard but has been abandoned. The
person served as a container for the groups on this endpoint. And in v1
we don't have a replacement for it. We just list the groups. But in v2
we have the container containing the groups.

I'm not aware of any integrations using this endpoint.
This is another breaking change. Well, our implementations of importing
a catalog just look for catalog items in the graph and don't use the
enterprise at all. So it doesn't break OFN. I don't know if there are
any platforms out there importing from OFN.

If we didn't want to change v1 then we would need to distinguish between
versions within each controller. It would be nice to know if this would
break anything or not. We don't know who is consuming our API and in
which way...
@mkllnk mkllnk self-assigned this Jun 5, 2026
@mkllnk mkllnk added the api changes These pull requests change the API and can break integrations label Jun 5, 2026
@github-project-automation github-project-automation Bot moved this to All the things 💤 in OFN Delivery board Jun 5, 2026
@mkllnk mkllnk marked this pull request as ready for review June 5, 2026 06:48
@mkllnk mkllnk moved this from All the things 💤 to Code review 🔎 in OFN Delivery board Jun 5, 2026
Comment thread engines/dfc_provider/spec/requests/supplied_products_spec.rb

@rioug rioug left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good 👍

@dacook dacook left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great to see the multi-versioning coming together, well done!
Should we add the label "minor breaking change"?

@dacook dacook moved this from Code review 🔎 to Ready to go 🚀 in OFN Delivery board Jun 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

api changes These pull requests change the API and can break integrations

Projects

Status: Ready to go 🚀

Development

Successfully merging this pull request may close these issues.

3 participants