Do people still design rest-ful APIs? I often find I end up needing to do RPC-like things that make the API end up as a weird hybrid. I'm on the verge of abandoning the idea of trying to be rest-ful at all, so it's less incohesive.
One of the things we insisted on building our internal ML platform was that every functionality should be accessible through an API.
This is scar tissue from our many past projects that delivered value to clients, but could not easily be leveraged as building blocks to do something else, especially when you have different stacks.
So now, we always strive to make everything that the platform can do possible through an API call, from scheduling a training job, to deploying a model, or invoking functionality from dynamically loaded applications, which also expose their API.
"Anything you can do with point and click should be accessible with an API call." guides us.
For the public API of a major service? Yes, REST is definitely still around. REST or at least REST-like APIs are still almost universal in my experience.
Surprising question, as I think REST is probably the leading paradigm for public APIs. At least in terms of what people call their API. What RESTful actually is varies from person to person.
Honestly, prefer GraphQL -- it's more like designing a schema which you may already be doing in your database anyway. The client decides which data in what shape it fetches.
If you're designing an internal API to power a rich client app, yes. If you're designing an API for developers to interface with you SaaS, plain old HTTP is a better choice, even if it's only RESTful in a hand wavy sense.
