Update Supported Addons API to include expanded support data

[Cheddam]

Following on from #220, we should expose the additional support data in the output of the Supported Addons API. This would be a breaking change in schema, so may require versioning the API endpoint.

[robbieaverill]

This would be a breaking change in schema, so may require versioning the API endpoint.

Are you referring to https://addons.silverstripe.org/api/supported-addons here? If so, I see what you mean - changing from an array to an object would be breaking, and adding a new key to the schema may not be the cleanest solution.

Not trying to say we shouldn't follow a good API design practice by versioning it, but maybe we could just add a new API endpoint instead?

• /api/v2/addons - in future, could have a paginated list of addons
• /api/v2/addons/supported - new supported list including support version constraints and timestamps from/to (this ticket)
• /api/v2/addon(s?)/foo/bar - detail view for a foo/bar module, including rating data
• /api/v2/addon(s?)/foo/bar/rating(?) - only ratings data for foo/bar module (is this needed?)
• /api/v2/addons/ratings?addons=silverstripe/framework - existing endpoint, not sure how we could make this more "restful" since it's an aggregated result. Maybe this could be copied through unchanged.

We could redirect /api/rating(s) to /api/v1/rating(s) to prevent it from breaking, OR we could just add the new endpoints to /api and continue without versioning it (feel free to kick me when I get home for suggesting this if you want to).

[robbieaverill]

Also FYI we use justinrainbow/json-schema in cow for JSON schema definition - seems to work well

[Cheddam]

"Versioning the endpoint" and "adding a /v2/ endpoint" are the same thing in my mind - I should have been more explicit about what I was suggesting, sorry!

I like your suggested endpoints - some of them aren't necessary to cover the scope of this issue, but representing supported addons as a subset of all addons certainly makes sense to me.

I think most HTTP clients will gracefully handle a 301 for the existing endpoints if we shift them to use a /v1/ prefix, and from a cleanliness angle it would be ideal, but it might not be necessary as long as the new endpoints are under /v2/.

[ScopeyNZ]

We could do a GraphQL endpoint 🤔

[Cheddam]

[robbieaverill]

We can use GraphQL now!

[chillu]

Thinking of working on this during Hackday. It's somewhat on the path to identifying issues mentioned in our Helpdesk, for the upcoming Experience Debt work.

[robbieaverill]

@chillu FYI if you do you will need to add in most of the supported modules again (it's a checkbox on the Addon record in the CMS) since we lost the DB a couple of months ago. We haven't gotten around to re-adding them all yet.