That's because you are thinking that the representation of a resource is the resource.
"The map is not the territory".
A PUT is a way for the client to transfer its representation of a resource to the server. There's nothing that stops the server from changing the state of that resource independently and asynchronously.
> The verbs quickly lose their meaning
That's because people tend to think in terms of CRUD, POST is Create, GET is Read, PUT/PATCH are Update, DELETE is Delete.
But that's misinterpreting things:
POST is to transfer the state of a new resource that has been created by the client. That resource might be subject to a long running business process (eg a Sales Order). That Sales Order will change its state as it progresses through the business process.
GET is a way for a client to request the transfer of a server's representation of an existing resource. It should do a GET to synchronize it's understanding of the current state. Use of E-tags etc allow for caching and avoiding stale changes.
PUT/PATCH is a way for a client to transfer a change in the representation of a resource to the server. For example, changing the delivery address. Often though, these attributes should be resources in their own right (eg /order/id/delivery-instructions). There is nothing to stop an initial post of the Sales Order creating the subresources as part of the processing of the POST. If you use JSON API and/or JSON-LD etc, you can provide backwardly compatible extensions in a response that older clients will ignore and newer clients can use.
DELETE is a way for the client to say that as far as it is concerned, the resource no longer exists. In the Sales Order example, it could represent the cancellation of the order, but might be rejected by the server (eg if it has already been shipped), or it might trigger something else (eg a refund).
> gRPC does away with the verbs entirely
gRPC forces the protocol to be "verb first" and focus on defining the behavior of those verbs. For each one, it has to clarify the idempotency, the state of the things being changed, how to find out about those changes, the different process errors that can occur, etc etc.
The trouble with gRPC is that it throws away everything that was learned in the "SOAP wars" of the 2005-10 period, where "enterprise suppliers" were desperate to keep their moats by defining ever more complex protocols on top of RPC to cover up the cracks and problems. An example, WS-ADDRESS, a standard for naming things over an RPC pipe that replicates the entire URL definition, but over a layer of RPC that was being tunnelled through port 80. WS-SECURITY, which did what TLS and HTTP Authorization does, but again, over layers of RPC and XML over HTTP over SSL.
All of that crap was unnecessary but was created because the idea of dealing with the nouns instead of the verbs is harder, because you have to think through the processes and changes in terms of state machines and events, instead of imperative processing where state is distributed and indeterminate.
> gRPC would let people focus on the actual problems at play
gRPC exposes the random distractions of one side's internal processing activities instead of focusing on how the two sides of a process co-ordinate and co-operate.
"The map is not the territory".
A PUT is a way for the client to transfer its representation of a resource to the server. There's nothing that stops the server from changing the state of that resource independently and asynchronously.
> The verbs quickly lose their meaning
That's because people tend to think in terms of CRUD, POST is Create, GET is Read, PUT/PATCH are Update, DELETE is Delete.
But that's misinterpreting things:
POST is to transfer the state of a new resource that has been created by the client. That resource might be subject to a long running business process (eg a Sales Order). That Sales Order will change its state as it progresses through the business process.
GET is a way for a client to request the transfer of a server's representation of an existing resource. It should do a GET to synchronize it's understanding of the current state. Use of E-tags etc allow for caching and avoiding stale changes.
PUT/PATCH is a way for a client to transfer a change in the representation of a resource to the server. For example, changing the delivery address. Often though, these attributes should be resources in their own right (eg /order/id/delivery-instructions). There is nothing to stop an initial post of the Sales Order creating the subresources as part of the processing of the POST. If you use JSON API and/or JSON-LD etc, you can provide backwardly compatible extensions in a response that older clients will ignore and newer clients can use.
DELETE is a way for the client to say that as far as it is concerned, the resource no longer exists. In the Sales Order example, it could represent the cancellation of the order, but might be rejected by the server (eg if it has already been shipped), or it might trigger something else (eg a refund).
> gRPC does away with the verbs entirely
gRPC forces the protocol to be "verb first" and focus on defining the behavior of those verbs. For each one, it has to clarify the idempotency, the state of the things being changed, how to find out about those changes, the different process errors that can occur, etc etc.
The trouble with gRPC is that it throws away everything that was learned in the "SOAP wars" of the 2005-10 period, where "enterprise suppliers" were desperate to keep their moats by defining ever more complex protocols on top of RPC to cover up the cracks and problems. An example, WS-ADDRESS, a standard for naming things over an RPC pipe that replicates the entire URL definition, but over a layer of RPC that was being tunnelled through port 80. WS-SECURITY, which did what TLS and HTTP Authorization does, but again, over layers of RPC and XML over HTTP over SSL.
All of that crap was unnecessary but was created because the idea of dealing with the nouns instead of the verbs is harder, because you have to think through the processes and changes in terms of state machines and events, instead of imperative processing where state is distributed and indeterminate.
> gRPC would let people focus on the actual problems at play
gRPC exposes the random distractions of one side's internal processing activities instead of focusing on how the two sides of a process co-ordinate and co-operate.