Являются ли они основными отличиями между RestSharp и ServiceStack Client Code?

Я не смог сделать окончательный выбор и надеялся, что кто-то (или комбинация из нескольких человек) может указать на различия между использованием клиентских сервисов RestSharp и ServiceStack (имея в виду, что я уже пользуюсь ServiceStack для мой сервис). Вот что я до сих пор (различия только). Список довольно небольшой, поскольку они действительно очень похожи:

ServiceStack

Pros

  • Свободная проверка от уже созданных объектов POCO службы
  • Один API для клиента и службы
  • Код читается лучше (т.е. Get < > (), Post < > ())

Против

  • Некоторые из моих строк должны быть записаны (т.е. если я делаю запрос GET с параметрами запроса, я должен создать эту строку в своем коде)
  • Я должен создать другой класс для каждого типа запроса/ответа (JsonServiceClient, XmlServiceClient)

RestSharp

Pros

  • Почти все может быть POCO (т.е. если я делаю запрос GET с параметрами запроса, я просто добавляю параметры через код)
  • Переключение между типами запроса/ответа прост (request.RequestFormat = DataFormat.Json/Xml)

Против

  • Ручная проверка (кроме тех, что указаны в аннотации данных)
  • Два API для обучения (это незначительно, поскольку они оба довольно просты)
  • Код не так читается с первого взгляда (т.е. request.Method = Get/Post.. и главный вызов - Execute <T> ())

Я склонялся к RestSharp, поскольку он больше склоняется к прямому использованию POCO и очень мало манипулирует строкой, однако я считаю, что ServiceStack может быть приемлемым для получения проверки и кода, который легче читать.

Итак, вот вопросы:

  • Что вы предпочитаете?
  • Почему одна над другой?

Я знаю, что это не полностью субъективный вопрос, но, как минимум, я ищу ответ на этот вопрос (который субъективен):

  • Являются ли какие-либо из моих находок неправильными и/или есть ли что-то, что я пропустил?

Ответы

Ответ 1

В качестве руководства по проекту ServiceStack я могу указать некоторые функции клиентов ServiceStack Service:

Клиенты ServiceStack Service уверены в потреблении веб-сервисов ServiceStack и его соглашений. т.е. они имеют встроенную поддержку структурированной проверки и обработки ошибок, а также все клиенты реализуют один и тот же интерфейс, чтобы вы могли тот же самый unit test, который будет использоваться в качестве теста интеграции для каждого из клиентов службы JSON, JSV, XML, SOAP и даже Protobuf, что позволяет вы можете легко изменить конечную точку/формат, который использует ваша служба без изменений кода.

В основном, если вы используете веб-службы ServiceStack, я бы рекомендовал использовать клиенты ServiceStack, которые позволят вам повторно использовать ваши DTO, с которыми вы определили свои веб-сервисы, предоставив вам типичный API-интерфейс от конца до конца.

Если вы потребляете сторонний API, я бы рекомендовал RestSharp, который является клиентом REST общего назначения, который хорошо подходит для этой задачи. Кроме того, поскольку ServiceStack просто возвращает чистые DTO по проводу, он также будет легко расходуться из RestSharp, который, если вы предпочитаете его API, также является хорошим вариантом.

ОБНОВЛЕНИЕ - Использование клиентских сервисов ServiceStack HTTP

ServiceStack теперь предоставляет альтернативный вариант для использования сторонних API с его методами расширения HTTP-клиента, который обеспечивает DRY, читаемый API вокруг общих шаблонов доступа HttpWebRequest, например:

List<GithubRepo> repos = "https://api.github.com/users/{0}/repos".Fmt(user)
    .GetJsonFromUrl()
    .FromJson<List<GithubRepo>>();

Расширения URL

var url ="http://api.twitter.com/statuses/user_timeline.json?screen_name={0}"
    .Fmt(name);
if (sinceId != null)
    url = url.AddQueryParam("since_id", sinceId);
if (maxId != null)
    url = url.AddQueryParam("max_id", maxId);

var tweets = url.GetJsonFromUrl()
    .FromJson<List<Tweet>>();

Альтернативный тип содержимого

var csv = "http://example.org/users.csv"
    .GetStringFromUrl(acceptContentType:"text/csv");

Дополнительные примеры доступны на странице HTTP Utils wiki.