Рекомендации-выбрасывание исключений из веб-службы

У нас есть веб-служба ASMX, которую мы вызываем из нашего ASP.NET приложение с использованием ajax (jQuery).

Типичным примером из наших веб-методов будет что-то вроде: 

[WebMethod]
public void DoSomething(BusinessObject myParameter)
{

    try
    {
       BL.DoSomethingWithParam(myParameter);
    }
    catch(Exception ex)
    { 
        //logic to log the actual exception goes here
        //and then we throw a more user-friendly error as so:
        throw new Exception("Unable to perform action such an such");
    }
}

На стороне клиента у нас было бы что-то вроде этого: 

$.ajax({
   type: "POST",
   url: "WebService.asmx/DoSomething",
   data: "{}",
   contentType: "application/json; charset=utf-8",
   dataType: "json",
   success: function(result) {
      //do something with result.d
    },
   error: function(xhr, ajaxOptions, thrownError){ 
      alert($.parseJSON(xhr.Response.Text).Message);
   }
});

Есть несколько проблем с вышеуказанным подходом, которые я хочу исправить:

  1. Когда мы тестируем наше приложение локально на наших коробках, Internet Explorer отображает фактическое сообщение об ошибке, которое мы выбрасываем на исключение throw new строка на нашем веб-методе (в случае кода примера, предоставленного: "невозможно выполнить действие такое-то") , но , когда мы развертываем в среде stage и тестируем удаленно; он больше не отображает ошибку, которую мы выбрасываем, а скорее это: "There has been an error processing your request."
  2. В Firefox (мы больше не тестировали браузеры), он вообще ничего не показывает, но Firebug показывает ошибку HTTP 500, которая выбрасывается.

В заключение мы не рассматриваем это должным образом, поэтому мои вопросы являются:

  1. Как лучше всего передать эти ошибки на клиентскую сторону и обеспечить согласованное поведение среди всех браузеров, как при локальном, так и удаленном тестировании?
  2. Почему IE не ломается так же, как Firefox? Конечно, тестирование удаленно IE тоже ломается, не показывая реальное сообщение об ошибке и заменяя его на generic There has been an error processing your request, но почему Firefox не делает то же самое?
  3. учитывая тот факт, что этот веб-сервис будет также потребляться другими Java Веб-приложения внутри компании, как лучше всего поддерживать взаимодействие с этими приложениями? Как мы можем все еще бросать эти исключения в наши веб-методы и иметь приложение Java, способное поймать их и обработать их соответствующим образом?
Один из вариантов, который мы реализовали -на данный момент мы все еще находимся на стадии разработки - это просто вернуть строку из наших веб-методов, когда происходит ошибка, но это действительно уродливый Хак/неэлегантный способ сделать это.

Примечание : не спрашивайте меня откуда приходит сообщение "произошла ошибка при обработке вашего запроса"? У меня нет ни малейшего представления. В нашем коде нет ничего, что могло бы вернуть это сообщение.

1 3
jquery json asmx

1 ответ:

Я не знаю, появился ли еще "правильный" способ из-за того, что способ использования веб-сервисов меняется так быстро, и, в конечном счете, любой клиент, созданный для использования сервиса, способен обрабатывать любой выбранный вами метод. Я не сомневаюсь, что в конечном счете один из них будет изобретен, но пока это зависит от вас.

Тем не менее, постарайтесь избежать некоторых из наиболее распространенных ловушек, которые я видел в прошлом.
  1. отсутствие согласованности: если ваш веб-сервис имеет несколько методов разрабатывают способ, чтобы все они могли сообщать об ошибках одним и тем же способом, чтобы сделать ваши методы более удобными для использования. Лично я предпочитаю следовать по стопам стеков протоколов и использовать какой-то согласованный заголовок. Создайте результирующие сообщения с общим заголовком, чтобы одна и та же логика могла использоваться во всем коде клиента для определения того, был ли вызов метода успешным.
  2. Нет поддержки для нескольких сообщений об ошибках: иногда происходит несколько сбоев. Ослепление клиент к вторичной ошибке может быть помехой и замедлять попытки отладки.
  3. отсутствие идентификации для сообщений об ошибках: если ошибка является результатом того, что определенное поле является недопустимым, позвольте клиенту программно определить, какое поле является виновником на основе предоставленной Вами информации.

Подход, с которого я обычно начинаю в эти дни, выглядит примерно так: 

{
    Success: bool,
    Errors[]: {
        Id: string,
        Source: string,
        Message: string
    },
    Message: { *Method specific structure* }
}
6