Personally I’d go for REST as your data API - that way you can represent your data however you like - in-game, on a website, wherever, because ultimately it’s just JSON. You can even implement authentication for users if you want to.
So your layout would be something like:
api.mygame.com - REST
api.mygame.com/news - NEWS endpoint.
api.mygame.com/profile - PROFILE endpoint.
mygame.com - WEBSITE feeding off the API.
So you could have an API endpoint
https://api.mygame.com/news that spat out the 10 latest news articles, and so on. Some endpoints could require authentication - which is a fancy way of sending an API key along with the request. The API key is associated with a USER, so if you had an endpoint
https://api.mygame.com/profile it would return any user-specific data, etc… (or 403 forbidden if not logged in).
This way you have a data-driven backend that can be represented in any way at all. It’s really handy when it comes to updating front-end GUIs because the data end doesn’t change.
In addition there’s really no issue at all to incorporating your REST API within your game for updating statistics, in-game purchases or whatever. It’s just a very elegant way of dealing with data over multiple platforms and languages. A unification of sorts.
If we look at jMonkeyStore as an example - anyone could create data from its API - or anything - including a SDK.
https://jmonkeystore.com/api/page/top/ - displays the top assets
https://jmonkeystore.com/api/page/38308161-c3cf-4e23-8754-528ca8387c11 - Minie Physics Library
It’s all just JSON that can be integrated anywhere.