| Philosophically the difference is a collection of resources vs a single connected data model and enforced object representation. The single data model lets you provide resource join requests and the enforced encoding lets the service select only desired fields. Field query params could be provided by web frameworks but they can't be fundamental because REST doesn't imply json or even resources with fields. Similarly, no fields means no join syntax. It will always be a bolt on solution for REST apis. That said, I feel like GraphQL has a flaw around multiple schemas/services. You can build a rest API as a collection of any endpoints of services and because you were doing all the work anyway it doesn't feel strange. I'm no GraphQL expert but it seems like stitching multiple schemas and joining across them isn't possible from a client perspective. I'm not sure how this plays out in practice. I would feel much better about GraphQL if it was a client side library that kept the query syntax. In theory something like that could wrap any number of REST services. REST services could opt in to added functionality like query joining and field filtering as needed. Missing functionality would fall back to the client. If we're taking requests for how to take the improvements of GraphQL into REST, that would be my suggestion. |