Response code for HTTP PUT with empty data
What is the most common/industry standard response code for HTTP PUT when:
- Client made a well-formed request and
- The content of the file/message/data is empty and
- Because of that nothing has been changed on the server/in the database
In my specific case the client sends HTTP PUT with an empty JSON like this:
{}
while I expect something more like this:
{
key1: {
something: value,
something2:value2
},
key2: {
something: value3,
something: value4
}
}
which in my case would translate to 4 new rows being upserted to the database.
I am considering either 400 (because maybe it is a bad request when you call a HTTP PUT but you don't have anything to put there), 200, 204 and 304.
My question is different from this and this because they are about HTTP GET method, and is different from this because while it is about HTTP PUT the answer doesn't address my case.
http server httpresponse put
asked Nov 22 '18 at 16:04
kukiskukis
2,74421835
add a comment |
What is the most common/industry standard response code for HTTP PUT when:
- Client made a well-formed request and
- The content of the file/message/data is empty and
- Because of that nothing has been changed on the server/in the database
In my specific case the client sends HTTP PUT with an empty JSON like this:
{}
while I expect something more like this:
{
key1: {
something: value,
something2:value2
},
key2: {
something: value3,
something: value4
}
}
which in my case would translate to 4 new rows being upserted to the database.
I am considering either 400 (because maybe it is a bad request when you call a HTTP PUT but you don't have anything to put there), 200, 204 and 304.
My question is different from this and this because they are about HTTP GET method, and is different from this because while it is about HTTP PUT the answer doesn't address my case.
http server httpresponse put
asked Nov 22 '18 at 16:04
kukiskukis
2,74421835
Any of the people voting to close bother to explain their reasoning?
– kukis
Nov 22 '18 at 16:11
add a comment |
What is the most common/industry standard response code for HTTP PUT when:
- Client made a well-formed request and
- The content of the file/message/data is empty and
- Because of that nothing has been changed on the server/in the database
In my specific case the client sends HTTP PUT with an empty JSON like this:
{}
while I expect something more like this:
{
key1: {
something: value,
something2:value2
},
key2: {
something: value3,
something: value4
}
}
which in my case would translate to 4 new rows being upserted to the database.
I am considering either 400 (because maybe it is a bad request when you call a HTTP PUT but you don't have anything to put there), 200, 204 and 304.
My question is different from this and this because they are about HTTP GET method, and is different from this because while it is about HTTP PUT the answer doesn't address my case.
http server httpresponse put
asked Nov 22 '18 at 16:04
kukiskukis
2,74421835
What is the most common/industry standard response code for HTTP PUT when:
- Client made a well-formed request and
- The content of the file/message/data is empty and
- Because of that nothing has been changed on the server/in the database
In my specific case the client sends HTTP PUT with an empty JSON like this:
{}
while I expect something more like this:
{
key1: {
something: value,
something2:value2
},
key2: {
something: value3,
something: value4
}
}
which in my case would translate to 4 new rows being upserted to the database.
I am considering either 400 (because maybe it is a bad request when you call a HTTP PUT but you don't have anything to put there), 200, 204 and 304.
My question is different from this and this because they are about HTTP GET method, and is different from this because while it is about HTTP PUT the answer doesn't address my case.
http server httpresponse put
http server httpresponse put
asked Nov 22 '18 at 16:04
kukiskukis
2,74421835
asked Nov 22 '18 at 16:04
kukiskukis
2,74421835
asked Nov 22 '18 at 16:04
kukiskukis
2,74421835
asked Nov 22 '18 at 16:04
kukiskukis
2,74421835
asked Nov 22 '18 at 16:04
kukiskukis
2,74421835
2,74421835
Any of the people voting to close bother to explain their reasoning?
– kukis
Nov 22 '18 at 16:11
add a comment |
Any of the people voting to close bother to explain their reasoning?
– kukis
Nov 22 '18 at 16:11
Any of the people voting to close bother to explain their reasoning?
– kukis
Nov 22 '18 at 16:11
Any of the people voting to close bother to explain their reasoning?
– kukis
Nov 22 '18 at 16:11
add a comment |
1 Answer
1
active
oldest
votes
A PUT request should replace what was on the server at the specified uri.
So if the resource at the uri already was empty, and the new resource that's being put is also empty, nothing changed but it's still a success, so 200 OK is fine.
If the resource didn't exist and you create a new 0-byte resource, 201 Created might be more appropriate.
If the resource did exist but it was not empty, and you send an empty PUT request, it should replace the existing resource with an empty one.
This is where you are going wrong, because PUT should not be used for a per-record "upsert" like you are doing.
If the PUT request you state was semantically correct, it should wipe out all existing records tied to that location.
What you probably want is PATCH or POST.
answered Nov 22 '18 at 16:11
EvertEvert
40.7k1569123
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53434680%2fresponse-code-for-http-put-with-empty-data%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
A PUT request should replace what was on the server at the specified uri.
So if the resource at the uri already was empty, and the new resource that's being put is also empty, nothing changed but it's still a success, so 200 OK is fine.
If the resource didn't exist and you create a new 0-byte resource, 201 Created might be more appropriate.
If the resource did exist but it was not empty, and you send an empty PUT request, it should replace the existing resource with an empty one.
This is where you are going wrong, because PUT should not be used for a per-record "upsert" like you are doing.
If the PUT request you state was semantically correct, it should wipe out all existing records tied to that location.
What you probably want is PATCH or POST.
answered Nov 22 '18 at 16:11
EvertEvert
40.7k1569123
add a comment |
A PUT request should replace what was on the server at the specified uri.
So if the resource at the uri already was empty, and the new resource that's being put is also empty, nothing changed but it's still a success, so 200 OK is fine.
If the resource didn't exist and you create a new 0-byte resource, 201 Created might be more appropriate.
If the resource did exist but it was not empty, and you send an empty PUT request, it should replace the existing resource with an empty one.
This is where you are going wrong, because PUT should not be used for a per-record "upsert" like you are doing.
If the PUT request you state was semantically correct, it should wipe out all existing records tied to that location.
What you probably want is PATCH or POST.
answered Nov 22 '18 at 16:11
EvertEvert
40.7k1569123
add a comment |
A PUT request should replace what was on the server at the specified uri.
So if the resource at the uri already was empty, and the new resource that's being put is also empty, nothing changed but it's still a success, so 200 OK is fine.
If the resource didn't exist and you create a new 0-byte resource, 201 Created might be more appropriate.
If the resource did exist but it was not empty, and you send an empty PUT request, it should replace the existing resource with an empty one.
This is where you are going wrong, because PUT should not be used for a per-record "upsert" like you are doing.
If the PUT request you state was semantically correct, it should wipe out all existing records tied to that location.
What you probably want is PATCH or POST.
answered Nov 22 '18 at 16:11
EvertEvert
40.7k1569123
A PUT request should replace what was on the server at the specified uri.
So if the resource at the uri already was empty, and the new resource that's being put is also empty, nothing changed but it's still a success, so 200 OK is fine.
If the resource didn't exist and you create a new 0-byte resource, 201 Created might be more appropriate.
If the resource did exist but it was not empty, and you send an empty PUT request, it should replace the existing resource with an empty one.
This is where you are going wrong, because PUT should not be used for a per-record "upsert" like you are doing.
If the PUT request you state was semantically correct, it should wipe out all existing records tied to that location.
What you probably want is PATCH or POST.
answered Nov 22 '18 at 16:11
EvertEvert
40.7k1569123
answered Nov 22 '18 at 16:11
EvertEvert
40.7k1569123
answered Nov 22 '18 at 16:11
EvertEvert
40.7k1569123
answered Nov 22 '18 at 16:11
EvertEvert
40.7k1569123
40.7k1569123
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53434680%2fresponse-code-for-http-put-with-empty-data%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Any of the people voting to close bother to explain their reasoning?
– kukis
Nov 22 '18 at 16:11