For example, you have a POST request and a PUT request that returns the whole json object of an entity that was created or updated. You have a get request for this.
Would it make sense to:
IMO it should be reasonable doable, when you have tested the GET request before that. e.g. checking its result in the database.
I’m asking without having your context, you can answer for yourself:
How much are you concerned about this and what are other priorities?
Once you have looked it up by yourself manually, how much do you expect to change this?
Why would it be important to check this repeatedly by automation?
I would assume myself having more important things to check (more system behavior related) and would check this only once manual. Not writing automation for this.
I often check (“technical”) details of an API call itself most times just once and try to automate more user scenarios.
tl;dr:
Are you a asking “How can I make this check reliable?” or “Should be I concerned that this is likely to fail?” ?
The later is hard to answer for others.
Tbh I’m just pondering over the usefulness of such a check. The post request already returns the whole chunk, I assume it should do that by fetching data from the database and that’s exactly where the get request should the data from.
But then there’s the question if there’s a problem in the get request and in the automated checks there’s bound to be a check for it. And since its better to have a fresh data set for the get request why not pair it with the post request.
that doesn’t matter, it just send back what it created or should have created or it can give you an ID or it can give you nothing, that doesn’t always mean it’s created in the backend, especially if it’s asynchronous.
POST - to Created
GET to verify
PUT to Create or Replace (YES create or replace, according to official restful ways)
GET to verify
Patch to Update partial data
GET to verify
DEL the item
GET to verify it’s deleted.
That’s kind of the “whole” flow, you might not have all methods but always a GET afterwards to verify imho. Especially in an Async world 
There’s another point to this, a single source of truth.
What if the GET request has an issue?
What if the POST request is right and returning the right data but the GET request isn’t?
I think this dependent on the test design, I have code that tells me which attributes within each request are different and what value did they have. So even if the GET request is faulty, the console logs will tell me what went different between them.
Also, the only way to test the GET request is to make a POST first 
.
The dilemma(s):
Then your test will fail on the GET request and that’s what you want right? 
POST /Customer
Name: Kristof
Location: Belgium
Then GET / Customer/1
Name: Bob
Location: Belgium
Then here your test will fail and that’s good. Since you expect Kristof and not Bob.
Test data:
Name: Jason
Location: Belgium
POST /Customer
Name: Kristof
Location: Belgium
Then GET / Customer/1
Name: Kristof
Location: Belgium
a possibility
You post the name Kristof which is not the same as your test data?
Then in the GET you’ll still get an error since you expect Jason right? 
Ah! In both cases I’m quoting the responses.
So you sent Jason to POST but got Kristof in response and also got Kristof from GET.
IF you get a response from a post request (which normally it shouldn’t besides maybe an ID) then you can validate that also but it won’t be an “official” test imho.
Yes that was the scenario in my original post:
This has to come with a caveat YMMV, but it’s something I do all the time. The pay off hopefully comes via total upfront effort over time, but goodness when a chain of dependent tests goes wrong, the result is what I like to call a FUBAR cascade. Happened to me while I was sleeping last night. The initial API tests to create a number of accounts went TITSUP, so 85 subsequent tests failed*.
* In my defense, setting up the test data to do it the orthodox way would cross multiple databases and involve more than one ID field regime.
This is
what I referred to here
Have a check that the GET works. And not on by and API.
Yep that’s what I’ve concluded for this.
Not relying on the API responses and instead having another source of truth “test data object” or “data fetched directly from the DB” is the best way to go.
I believe it’s a great way to ensure that changes are accurately reflected in the database. Of course, I would delete the data to ensure there are no residual artifacts in the application that could cause any other automation issues.
Sometimes extra data might cause issues with other get methods