HTTP can be thought of as one specific case of a generic principles of Remote Procedure Call: you tell the server what you want with some variable field in the request, the server responds accordingly. By now, due to the complex interactivity of ‘Web 2.0,’ these same features are shoved in every field on the request: the URL, headers, the body—and each appserver and app understands them in their own way. However, originally the web was simpler, used static pages, and it was thought that the HTTP methods provided for the level of interactivity that would suffice. Notably, HTTP has plenty of methods that are used rarely, if ever, with some of them only seeing the light thanks to REST. E.g. PUT and DELETE were moribund before REST, and TRACE and PATCH are afaik still unseen. The takeaway is that HTTP's model of RPC didn't quite match the apps that followed, and apps implemented their own model with just GET and POST—but HTTP couldn't be thrown away by then.
REST did the exact opposite of what you're proposing, by noting that the HTTP methods serve the typical CRUD use-cases of most apps if PUT and DELETE are brought back.
Note also that HTTP methods have semantics assigned to them, that are honored by browsers and middleware like proxy servers: POST, PUT, DELETE and PATCH requests may have side effects and likely to not be idempotent, so client-side apps and middleware take caution to not fire these requests without express action from the user. In practice, poorly-designed web apps did use GET for non-safe actions, and e.g. the Google Web Accelerator prefetcher caused trouble by deleting bunch of data on such sites, so its beta was suspended soon after launch.
So, to answer the ‘can we’ question: sure, you just need to agree on a protocol that will tell the server app what action you want to perform, and then you put the arguments somewhere in the URL/body—such as the target item for the action. The set of actions is bounded only by specific apps, so you need an extensible protocol. But you'll need to let the client apps know which requests are safe, and probably to take other nuances into account, such as cache-control.