public DoStuff(int level)
{
// DoStuff(level);
DoStuff(level++);
// level = level + 1;
// here, level's value is 1 greater than when it came in
}
Это на самом деле увеличивает значение уровня.
public DoStuff(int level)
{
// int iTmp = level + 1;
// DoStuff(iTmp);
DoStuff(level+1);
// here, level's value hasn't changed
}
на самом деле не увеличивает значение уровня.
Не огромная проблема перед вызовом функции, но после вызова функции, значения будут отличаться.
Я не думаю, что какой-либо клиент RESTful будет ожидать, что он будет смотреть на фразу причины, чтобы выяснить, что пошло не так; большинство служб RESTful, которые я видел / использовал, будут отправлять стандартную информацию о статусе и расширенное сообщение в теле ответа. sendError (int, String)
идеально подходит для этой ситуации.
Если вы используете Tomcat, см. настройка org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER:
http://tomcat.apache.org/tomcat-5.5-doc/config/systemprops.html
См. Эту страницу для получения некоторых подробностей об исходной уязвимости:
http://www.securityfocus.com/archive/1/archive/1/495021/100 / 0 / Threadaded
Я не совсем знаком с «лучшими практиками» REST. Но я знаю, что эта концепция основана на HTTP и как она должна работать естественным образом. Так как насчет использования mime-типа и простого текста внутри тела для сообщения об ошибке приложения, такого как application / myapp-exception или какое-то «Bla bla»? Вы можете предоставить для этого клиентскую библиотеку.
Я бы не стал использовать коды ответа HTTP для ошибок приложения. Потому что мне нравится знать, что дает сбой: мое приложение или мой HTTP-сервер.
(Надеюсь, здесь я тоже увижу несколько советов по передовой практике.)
После вашего разъяснения я попробовал это в Tomcat. При выполнении
response.sendError(HttpServletResponse.SC_BAD_REQUEST, "message goes here");
в качестве первой строки ответа возвращается
HTTP/1.1 400 message goes here
.
Должна быть проблема с контейнером сервлета, который вы используете.
Не совсем понятно, чего вы пытаетесь достичь. Моей первой мыслью был sendError, но вы говорите, что он не делает того, что вы хотите ... вы смотрели на создание набора «ответов об ошибках», означающих конкретный контент xml или JSON (или любой другой язык, который вы используете в качестве языка передачи), который содержит сообщение об ошибке или код и любую другую полезную информацию?
Некоторое время назад я делал что-то подобное для служб RESTful на основе Spring-mvc, и это работало хорошо, но вам нужно в значительной степени перехватывать и обрабатывать каждое исключение, чтобы клиент не получение общего сообщения 500 или что-то в этом роде. Для этого хорошо сработали средства разрешения исключений Spring.
Надеюсь, это поможет ... если нет, возможно, немного больше ясности в том, что вы пытаетесь достичь. Извините, если я веду себя глупо и упускаю что-то очевидное.
I think the sendError
should do it, but your application server may be failing... IBM WebSphere 3.5 failed on me a long time ago while Tomcat would propagate the message just fine; see JavaServer Pages (JSP) and JSTL - Error page: preserve header "HTTP/1.x 400 My message"? on the Sun forums.
Eventually I used the following workaround, but this is kind of JSP specific, and may in fact be old:
<%@ page isErrorPage="true" %>
<%
// This attribute is NOT set when calling HttpResponse#setStatus and then
// explicitely incuding this error page using RequestDispatcher#include()
// So: only set by HttpResponse#sendError()
Integer origStatus =
(Integer)request.getAttribute("javax.servlet.error.status_code");
if(origStatus != null) {
String origMessage =
(String)request.getAttribute("javax.servlet.error.message");
if(origMessage != null) {
response.reset();
response.setContentType("text/html");
// deprecated, but works:
response.setStatus(origStatus.intValue(), origMessage);
// would yield recursive error:
// response.sendError(origStatus, origMessage);
}
}
%>
And if you happen to test with Internet Explorer: disable "Show friendly HTTP error messages". (When not disabling that, IE has some odd requirement of some minimum length of the HTML content which, if not met, would —or will— make IE show its own error message instead. See also the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Main\ErrorThresholds
at Microsoft's Description of Hypertext Transport Protocol Error Messages.)
В веб-приложении Spring, работающем на Tomcat, я использую следующий bean-компонент:
import java.util.Map;
import java.util.Set;
import java.util.Map.Entry;
import org.springframework.beans.factory.InitializingBean;
public class SystemPropertiesInitializingBean implements InitializingBean {
private Map<String, String> systemProperties;
@Override
public void afterPropertiesSet() throws Exception {
if (null == systemProperties || systemProperties.isEmpty()) {
return;
}
final Set<Entry<String, String>> entrySet = systemProperties.entrySet();
for (final Entry<String, String> entry : entrySet) {
final String key = entry.getKey();
final String value = entry.getValue();
System.setProperty(key, value);
}
}
public void setSystemProperties(final Map<String, String> systemProperties) {
this.systemProperties = systemProperties;
}
}
И в applicationContext.xml:
<bean class="....SystemPropertiesInitializingBean">
<property name="systemProperties">
<map>
<entry key="org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER" value="true"/>
</map>
</property>
</bean>