I think that REST is not perfectly suitable for contemporary applications, which are simply too complicated for it to handle gracefully. The simplest example I can give is a /login, where no conventional method works (you're not GETting information, not POSTing nor PUTting some payload [and dear God don't use DELETE]). The ultimate solution would be a combination of REST and RPC of some sort, in my mind.
Lately I've been getting into GraphQL and I gotta say I fell in love with it, as I feel it is the replacement of REST I've looked for. They opted to put the whole query in a POST request (be it GET, POST, PUT or DELETE equivalent), but in a nice structure that is easy to follow and manage.
Actually the more I build complex apis, the more It messes my head around to stick with REST because of consistency issues.
For example, I would have a route to display all the shoes in a shoe store in GET /api/shoe, but getting the users liked shoes would be used through Post /api/shoe/liked because I authenticate the user with a JWT and I prefer to use a POST parameter because of the limit in GET queries and the fact post parameters are less easy to sniff than get... But this would work fine in GET because my tokens are not so long and my urls quite short but I do this to prevent any issues.
Also, it has for a moment make me wonder how complex it is to stick with only GET,POST,PUT,DELETE. An example is when you want to provide an "undo" feature.
Say you can trash a comment, or remove it permanently. Trashing would be seen as the equivalent of soft deleting, so why not use DELETE. But then you have the actual deletion, or maybe named destruction. Will you use DELETE to do this? Then the classic REST schema does not work anymore.
I feel like you, today REST gets less and less optimal for complex apps, GraphQL seems to be more suited.
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.
I think that REST is not perfectly suitable for contemporary applications, which are simply too complicated for it to handle gracefully. The simplest example I can give is a
/login, where no conventional method works (you're notGETting information, notPOSTing norPUTting some payload [and dear God don't useDELETE]). The ultimate solution would be a combination of REST and RPC of some sort, in my mind.Lately I've been getting into GraphQL and I gotta say I fell in love with it, as I feel it is the replacement of REST I've looked for. They opted to put the whole query in a POST request (be it GET, POST, PUT or DELETE equivalent), but in a nice structure that is easy to follow and manage.
Actually the more I build complex apis, the more It messes my head around to stick with REST because of consistency issues.
For example, I would have a route to display all the shoes in a shoe store in GET
/api/shoe, but getting the users liked shoes would be used through Post/api/shoe/likedbecause I authenticate the user with a JWT and I prefer to use a POST parameter because of the limit in GET queries and the fact post parameters are less easy to sniff than get... But this would work fine in GET because my tokens are not so long and my urls quite short but I do this to prevent any issues.Also, it has for a moment make me wonder how complex it is to stick with only GET,POST,PUT,DELETE. An example is when you want to provide an "undo" feature.
Say you can trash a comment, or remove it permanently. Trashing would be seen as the equivalent of soft deleting, so why not use DELETE. But then you have the actual deletion, or maybe named destruction. Will you use DELETE to do this? Then the classic REST schema does not work anymore.
I feel like you, today REST gets less and less optimal for complex apps, GraphQL seems to be more suited.