Will start this off with the explicit statement I am not ant-REST. :)
That said, I will respectfully disagree with you on your statement This makes designing the API easier and using the API more predictable.
While REST brings a lot of good with it, it is not a defined protocol but a set of ideas sitting atop HTTP. This can cause a ton of headaches, not the least of which is endless bikeshedding about things like entities, which verb to use (yes, GET is the accepted verb for retrieving data, but nothing forbids a POST), etc. Plus, doing operations under REST can be extremely confusing.
GRPC carries the benefit of being a defined protocol, leaving little room for confusion.
That said, I think the most promise right now is GraphQL because it allows you to expose data as needed, and the shape of the data can be defined by the caller, potentially saving a ton of data transfer and handling.
I was going to reply to this before you made the update, but you’ve basically said the things I was going to say :). My comment about it being “easier” was more in comparison to the status quo when it was created. I’d pick graphql if I were building an api today. That said, it also leaves quite a few of the hard problems up to the implementer.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Will start this off with the explicit statement I am not ant-REST. :)
That said, I will respectfully disagree with you on your statement This makes designing the API easier and using the API more predictable.
While REST brings a lot of good with it, it is not a defined protocol but a set of ideas sitting atop HTTP. This can cause a ton of headaches, not the least of which is endless bikeshedding about things like entities, which verb to use (yes, GET is the accepted verb for retrieving data, but nothing forbids a POST), etc. Plus, doing operations under REST can be extremely confusing.
GRPC carries the benefit of being a defined protocol, leaving little room for confusion.
That said, I think the most promise right now is GraphQL because it allows you to expose data as needed, and the shape of the data can be defined by the caller, potentially saving a ton of data transfer and handling.
Thanks for the write-up!
I was going to reply to this before you made the update, but you’ve basically said the things I was going to say :). My comment about it being “easier” was more in comparison to the status quo when it was created. I’d pick graphql if I were building an api today. That said, it also leaves quite a few of the hard problems up to the implementer.