java HTTP 状态代码 500 是否意味着没有出现其余错误代码
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/31084497/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Does HTTP Status Code 500 means that the rest error code are not occuring
提问by Moon
I am trying to update an object via REST API with an HTTP PUT request. I was getting different errors like 400 but now after amending my code and headers I am getting 500 which means that
我正在尝试使用 HTTP PUT 请求通过 REST API 更新对象。我收到了不同的错误，比如 400，但现在在修改我的代码和标题后，我收到了 500，这意味着
Internal Error 500 : The server encountered an unexpected
condition which prevented it from fulfilling the request.
Does this mean the following errors I don't have to worry about, meaning the operation is authorized, method is not forbidden etc etc
这是否意味着我不必担心以下错误，意味着操作已授权，方法未被禁止等
- Unauthorized 401
- PaymentRequired 402
- Forbidden 403
- Not found 404
- 未经授权的401
- 付款要求 402
- 禁止 403
- 未找到 404
p.s I am using JSON.
ps 我正在使用 JSON。
String json = "my json string with escape characters"
String st= "username:password";
byte[] encoded = Base64.encodeBase64(st.getBytes());
String credentials = new String(encoded);
String url= "http://localhost:10108/grc/api/contents/20081";
URL object=new URL(url);
HttpURLConnection con = (HttpURLConnection) object.openConnection();
con.setDoOutput(true);
con.setDoInput(true);
con.setRequestProperty("Content-Type", "application/json");
con.setRequestProperty("Accept","application/json");
con.setRequestProperty ("Authorization", "Basic " + credentials);
con.setRequestMethod("PUT");
JSONObject jsonObject = (JSONObject)new JSONParser().parse(json);
OutputStream os = con.getOutputStream();
os.write(jsonObject.toJSONString().getBytes());
os.flush();
int responseCode = con.getResponseCode();
My original JSON is following
我的原始 JSON 如下
{
"name": "Decommisioned CBU One",
"id": "2116",
"description": "Decommisioned CBU One",
"parentFolderId": "2115",
"fields": {
"field": [{
"dataType": "ID_TYPE",
"id": "29",
"name": "Resource ID",
"value": "2116"
}, {
"dataType": "STRING_TYPE",
"id": "63",
"name": "Comment"
}, {
"dataType": "INTEGER_TYPE",
"id": "60",
"name": "Created By",
"value": 6
}, {
"dataType": "DATE_TYPE",
"id": "59",
"name": "Creation Date",
"value": "2015-02-04T20:23:26.000+05:00"
}, {
"dataType": "STRING_TYPE",
"id": "57",
"name": "Description",
"value": "Decommisioned CBU One"
}, {
"dataType": "DATE_TYPE",
"id": "61",
"name": "Last Modification Date",
"value": "2015-02-04T20:23:26.000+05:00"
}, {
"dataType": "INTEGER_TYPE",
"id": "62",
"name": "Last Modified By",
"value": 6
}, {
"dataType": "STRING_TYPE",
"id": "58",
"name": "Location",
"value": "/_op_sox/Project/Default/BusinessEntity/Emirates NBD PJSC/Emirates NBD Bank/Wholesale Banking/(Decommissioned) Corporate Banking/Decommisioned CBU One/Decommisioned CBU One.txt"
}, {
"dataType": "STRING_TYPE",
"id": "56",
"name": "Name",
"value": "Decommisioned CBU One.txt"
}, {
"dataType": "STRING_TYPE",
"id": "66",
"name": "Orphan"
}, {
"dataType": "STRING_TYPE",
"id": "125",
"name": "OPSS-BusEnt:Business Entity Chart",
"value": "${\"labelKey\" : \"label.hierarchyDiagram.url\", \"path\" : \"/visualization/VizRenderer.jsp\", \"modes\" : [\"view\", \"edit\"],\n \"parameters\" :{\"oid\" : \"$objectId\",\"viz\" : \"EntityHierarchy\"},\n \"popUp\" : { \"windowAttributes\" : \"height=800,width=1000,menubar=no,status=no,toolbar=no,scrollbars=yes,resizable=yes,name=_blank\"\n }\n }"
}, {
"dataType": "STRING_TYPE",
"id": "124",
"name": "OPSS-BusEnt:Compliance Owner"
}, {
"dataType": "ENUM_TYPE",
"id": "121",
"name": "OPSS-BusEnt:Entity Type",
"enumValue": {
"id": "229",
"name": "Business",
"localizedLabel": "Business",
"index": 2,
"hidden": false
}
}, {
"dataType": "STRING_TYPE",
"id": "123",
"name": "OPSS-BusEnt:Executive Owner"
}, {
"dataType": "ENUM_TYPE",
"id": "133",
"name": "OPSS-BusEnt:In RCSA Scope",
"enumValue": {
"id": "227",
"name": "No",
"localizedLabel": "No",
"index": 2,
"hidden": false
}
}, {
"dataType": "MULTI_VALUE_ENUM",
"id": "122",
"name": "OPSS-BusEnt:In Scope"
}, {
"dataType": "STRING_TYPE",
"id": "126",
"name": "OPSS-BusEnt:Logo URL"
}, {
"dataType": "CURRENCY_TYPE",
"id": "132",
"name": "OPSS-BusEnt:Risk Appetite",
"baseAmount": 0.0,
"localAmount": 0.0
}]
},
"typeDefinitionId": "6",
"primaryParentId": "2112"
}
after removing linbreaks and using escape sequence, I am left with the follwowing string which I am using as my JSON
删除 linbreaks 并使用转义序列后，我留下了用作 JSON 的以下字符串
{ \"name\": \"Decommisioned CBU One\", \"id\": \"2116\", \"description\": \"Decommisioned CBU One\", \"parentFolderId\": \"2115\", \"fields\": { \"field\": [{ \"dataType\": \"ID_TYPE\", \"id\": \"29\", \"name\": \"Resource ID\", \"value\": \"2116\" }, { \"dataType\": \"STRING_TYPE\", \"id\": \"63\", \"name\": \"Comment\" }, { \"dataType\": \"INTEGER_TYPE\", \"id\": \"60\", \"name\": \"Created By\", \"value\": 6 }, { \"dataType\": \"DATE_TYPE\", \"id\": \"59\", \"name\": \"Creation Date\", \"value\": \"2015-02-04T20:23:26.000+05:00\" }, { \"dataType\": \"STRING_TYPE\", \"id\": \"57\", \"name\": \"Description\", \"value\": \"Decommisioned CBU One\" }, { \"dataType\": \"DATE_TYPE\", \"id\": \"61\", \"name\": \"Last Modification Date\", \"value\": \"2015-02-04T20:23:26.000+05:00\" }, { \"dataType\": \"INTEGER_TYPE\", \"id\": \"62\", \"name\": \"Last Modified By\", \"value\": 6 }, { \"dataType\": \"STRING_TYPE\", \"id\": \"58\", \"name\": \"Location\", \"value\": \"/_op_sox/Project/Default/BusinessEntity/Emirates NBD PJSC/Emirates NBD Bank/Wholesale Banking/(Decommissioned) Corporate Banking/Decommisioned CBU One/Decommisioned CBU One.txt\" }, { \"dataType\": \"STRING_TYPE\", \"id\": \"56\", \"name\": \"Name\", \"value\": \"Decommisioned CBU One.txt\" }, { \"dataType\": \"STRING_TYPE\", \"id\": \"66\", \"name\": \"Orphan\" }, { \"dataType\": \"STRING_TYPE\", \"id\": \"125\", \"name\": \"OPSS-BusEnt:Business Entity Chart\", \"value\": \"${\"labelKey\" : \"label.hierarchyDiagram.url\", \"path\" : \"/visualization/VizRenderer.jsp\", \"modes\" : [\"view\", \"edit\"],\n \"parameters\" :{\"oid\" : \"$objectId\",\"viz\" : \"EntityHierarchy\"},\n \"popUp\" : { \"windowAttributes\" : \"height=800,width=1000,menubar=no,status=no,toolbar=no,scrollbars=yes,resizable=yes,name=_blank\"\n }\n }\" }, { \"dataType\": \"STRING_TYPE\", \"id\": \"124\", \"name\": \"OPSS-BusEnt:Compliance Owner\" }, { \"dataType\": \"ENUM_TYPE\", \"id\": \"121\", \"name\": \"OPSS-BusEnt:Entity Type\", \"enumValue\": { \"id\": \"229\", \"name\": \"Business\", \"localizedLabel\": \"Business\", \"index\": 2, \"hidden\": false } }, { \"dataType\": \"STRING_TYPE\", \"id\": \"123\", \"name\": \"OPSS-BusEnt:Executive Owner\" }, { \"dataType\": \"ENUM_TYPE\", \"id\": \"133\", \"name\": \"OPSS-BusEnt:In RCSA Scope\", \"enumValue\": { \"id\": \"227\", \"name\": \"No\", \"localizedLabel\": \"No\", \"index\": 2, \"hidden\": false } }, { \"dataType\": \"MULTI_VALUE_ENUM\", \"id\": \"122\", \"name\": \"OPSS-BusEnt:In Scope\" }, { \"dataType\": \"STRING_TYPE\", \"id\": \"126\", \"name\": \"OPSS-BusEnt:Logo URL\" }, { \"dataType\": \"CURRENCY_TYPE\", \"id\": \"132\", \"name\": \"OPSS-BusEnt:Risk Appetite\", \"baseAmount\": 0.0, \"localAmount\": 0.0 }] }, \"typeDefinitionId\": \"6\", \"primaryParentId\": \"2112\" }
回答by OrigamiMarie
Unfortunately, HTTP status 500 is really just a catch-all for unexpected errors on the server. The error could be anywhere, even within the authentication code. So it's possible that the call is blowing up even before it would have issued a 401 response.
不幸的是，HTTP 状态 500 实际上只是服务器上意外错误的一个包罗万象的信息。错误可能在任何地方，甚至在身份验证代码中。因此，甚至在发出 401 响应之前，呼叫就可能被炸毁。
In a perfect world, 500 responses wouldn't happen because developers would catch all possible errors and return useful responses instead.
在完美的世界中，不会发生 500 个响应，因为开发人员会捕获所有可能的错误并返回有用的响应。
A service owner should be interested in and concerned about 500 errors, a client shouldn't be able to cause them (a determined client could use them to DOS the service). The best thing to do next is to contact the service owner and ask them to look in their logs for the cause of the error.
服务所有者应该对 500 个错误感兴趣并关注，客户端不应该导致它们（确定的客户端可以使用它们来对服务进行 DOS 处理）。接下来要做的最好的事情是联系服务所有者并要求他们查看他们的日志以找出错误的原因。
回答by Michael Aaron Safyan
Ultimately, it is up to the server to decide what status code to return, but the standard meaning of the 5xx status codes (as opposed to the 4xx status codes) is that something went wrong on the server-side of things (like the server performing a null dererefence or some other serious error), whereas the 4xx status codes means that there is something wrong with the client / request being sent.
最终，由服务器决定返回什么状态代码，但 5xx 状态代码（与 4xx 状态代码相反）的标准含义是服务器端出现问题（如服务器端）执行 null dererefence 或其他一些严重错误），而 4xx 状态代码意味着正在发送的客户端/请求有问题。
