Skip to main content

Nailing Down HTTP Methods

There has been some debate about when to use PUT versus PATCH versus POST in REST APIs. Having dealt with a variety of 3rd-party REST APIs now, I've become a little opinionated about how the various methods *should* be used. Here's my take:

The way I prefer to see PUT used is to submit a fully-formed replacement resource. In other words, if you are using PUT to update a resource, you probably will want to fetch the object from the resource initially, modify it and then PUT the entire modified object back to the resource.  If you are creating a new resource, use PUT only if you are creating your own resource ID (probably not a common use-case, since most resources will auto-assign their own IDs).


In contrast, PATCH can update any number of properties of a known resource without needing to submit the entirety of the resource. In most cases, PATCH is the right method for updates as it saves on bandwidth.

IMO, POST is the right method for creating a new resource, assuming IDs are auto-assigned. Note that POST doesn't need to know every property of a resource in order to create a new one, whereas PUT must. So if your client wants to start a transaction, for example, POST means they don't need to submit every property of a transaction to create one.  It makes life much easier on your client.

What this boils down to for me is that PUT should used only rarely for specific use-cases.

Comments

Popular posts from this blog

jQuery noUIslider Pip Label Customization

Recently, I was tasked with creating a slider element for a user to select their credit rating, of which the user can select from among: 'Poor', 'Fair', 'Good', 'Excellent' and 'Not Sure'.  Several problems presented themselves here: A drop-down box would be better, but that's not what the requirements specified. I already have several numeric sliders on my page and I want them all to match. I selected the jQuery noUi Slider library to create the numeric sliders. noUi Slider does not support string values - only numeric values. The "pips" (slider scale/labels) also does not support string values. Since the solution involved shifting my mindset, I wanted to document it here for future reference and maybe to help someone facing the same requirements. Here's my solution: Since there is really no numeric correlation to credit score (especially considering one of the options is "Not Sure"), I will just u...

Salesforce Apex: Replacing and/or Removing Apex Classes

Working with code within the constraints of Salesforce's workflow can be a challenge.  First , you have the restriction on changing anything in production.  Second , you have the requirement for 75% or greater unit test coverage.  Third , you have the fact that certain metadata cannot be pushed to production through a changeset (which means the only way to sync record IDs is by re-deploying the development environment from production). Fourth - and this is what I'd like to blog about today - you cannot delete classes from production through the Salesforce UI .  The only way to delete a class from production is to download the class (and its associated metadata file) into the Eclipse IDE (which you have previously set up with the Apex add-on), change the "status" flag to "Deleted", then deploy the changed metadata file to production.  And (here's the kicker)...sometimes it doesn't work because...reasons. So let's start with the workflow of a f...

More Laravel Magic - Touches

What is "touches"?  Well, anyone familiar with Linux/Unix is going to be familiar with the concept of "touching" a file.  Touching a file sets the "last modified" timestamp (or creates the file if it doesn't exist).  Knowing when a file was last modified can be very important for version control. Laravel has something similar for its model relations.  For example, lets say there is a club with many members.  When a member joins, leaves or gets a new role in the club, you might contend that the club has changed.  In terms of Laravel, you would want the club table's "updated_at" timestamp to reflect that change.  Enter the "touches" property... To make the magic happen in Laravel, you simply need to define the parent relationship and add it to the touches property like so: <?php class Club extends Model { /** * Touches (touch parent model when this model changes) */ protected $touches = [ ...