I once worked on a reasonably complex e-commerce system with millions of products, add-to-cart, taxes, promo codes, etc. Every so often, an order total changed between the time that the user saw the total on the confirmation screen and when they actually hit the button to place the order (which seems to be what happened here). This happened because of promo applicability changes, product price changes, products being de-listed, etc.
But it was relatively easy to prevent problems with this. When the user clicked the button to place the order, we sent along the expected order total, the expected item IDs to purchase, the expected tax, etc. In the backend, one of the last validation step before the order was finalized was just to compare the final order details against those expected values. If there were any differences, the order was rejected with an error message to try again. There were then monitors on these types of errors which would go off if there was a higher-than-normal frequency of these sorts of errors, so we could track down any bugs causing price discrepancies.
I'm kind of surprised that UberEats doesn't seem to have a similar validation step.
I do appreciate the structural parity that this has with Laravel's Eloquent ORM models--that is, a class to represent a specific database resource. It makes API requests feel like a close analogue to that Laravel-esque functionality.
That said, REST API endpoint are effectively just functions--you pass in params, you get a response. They only have a single operation possible on them, unlike ORM models which can do many things.
Whenever I've implemented a custom API client in PHP, boring old OOP seems to solve the problems stated in the article reasonably well:
class ApiConsumer {
function __construct($baseUrl, $credentials);
function operationFoo($paramOne, $paramTwo): FooResponse;
function operationBar($paramOne, $paramTwo): BarResponse;
}
But it was relatively easy to prevent problems with this. When the user clicked the button to place the order, we sent along the expected order total, the expected item IDs to purchase, the expected tax, etc. In the backend, one of the last validation step before the order was finalized was just to compare the final order details against those expected values. If there were any differences, the order was rejected with an error message to try again. There were then monitors on these types of errors which would go off if there was a higher-than-normal frequency of these sorts of errors, so we could track down any bugs causing price discrepancies.
I'm kind of surprised that UberEats doesn't seem to have a similar validation step.