Robert Buchanan, API Evangelist at Procter & Gamble
Yeah. So I think that's a miss in the industry. Um, and the reason why is because we talk about, and I'm going to, you know, hopefully I don't get flack from Roy Fielding, but my understanding of RESTful, um, and whatnot, is we should be able to define HTTP methods so that our actions are communicated in the methods, the verbs of what we're trying to do are communicated in the HTTP methods, but not necessarily in our payload structures or in our So a lot of times I see people, you know, get caught up in the conundrum of if they're trying to build an API to where they process orders, they're like, well, how do I cancel an order? Well, it could be a post and you take an event to cancel an order. It could be a put where you update the order, but now you're putting the control of what status it is into the consumer's hand. And then it could be a patch, but. Patches generally not used because they either don't do a json patch or they don't do a proper patch operation. They do like this merge or upsert system. And again, it goes back to you're putting that control in the consumer to do. However, if we created a cancel method and you just sent the order slash order ID with the cancel method, now your logic is very crisp and clear of, Hey, I need to cancel this order. I don't have to guess of, well, is it modifying the fulfillment address? Is it modifying this? And we actually would build more secure software because now we've reduced all the logic that goes into processing endpoints, which in turn, if we get to custom methods, more realistically, or, or more methods in general, we would then get to that Holy grail of hypermedia a lot easier because then when we pass around the links in payloads, They become easier to decipher programmatically versus like, well, is this a post that it's saying action of, you know, next, is that a post? Is it get, is it a, what, what is it? Right? We can clearly say what it is because the methods are available.
