Any sufficiently complex data model will run into an issue where you need a mechanism to selectively render resources differently for different purposes. Puttin

Any sufficiently complex data model will run into an issue where you need a mechanism to selectively render resources differently for different purposes. Putting new routes in place is a heavyweight way of doing this, and query-parameter mechanisms is a real pain. GraphQL started because RESTful APIs at FaceBook were causing great pain for their mobile clients (multiple round trips for data, full data sets, versioning issues on server and client). We experienced the same problem for similar (but smaller) datasets. I did a quick look for the fishworks commentary, but I can’t find the discussion (this was from before the Borgacle consumption of Sun) about how much of a mismatch it was to implement VM controls through a REST interface. Is it legit to POST /vm/:id/restart or should it be a PATCH /vm/:id with a payload of { "action": "restart" }? Or… Many advocates of a particular programming style (OO, REST, TDD are some of the more vocal, but FP advocates are right in there, too) seem to adopt the view that it is appropriate for everything. There’s definitely some impedance mismatch if you try to be REST “pure“ between that and the real world, the same as there will be if you go “pure“ for OO or FP for the same sort of things, but there will be different impedance mismatches. I really tried with HATEOAS, because it makes sense, but the overhead has turned out to outweigh the costs for everything we’ve needed.