Руководство по написанию обертки для REST API

Я написал несколько очень случайных оберток вокруг REST и менее структурированных веб-интерфейсов, но все просто для удовольствия, с очень небольшим вниманием к обнаружению и обработке ошибок, тайм-аутам и т.д.

Может кто-нибудь, пожалуйста, дать мне несколько указателей, как на практике, так и на ресурсы, для разработки надежной, профессиональной платформы .NET(или другой платформы) для REST API?

Вещи, которые пересекают мой разум:

Интерпретация кодов ошибок HTTP и ошибок протокола фильтрации из ошибок API.
Создание запросов на основе URL-адресов, возможно с подстановкой шаблонов и заменой токенов.
Соответствие обратных ссылок на запросы.
Как сопоставить модель OO с моделью REST. Некоторые запросы удовлетворяют статическим методам, например. получение списков и другие зависают посередине между static и экземпляром, может быть, простой шаблон поставщика со всеми статическими методами?

NEW: С тех пор я нашел это почти слишком основное руководство для создания Yahoo REST-вызовов, но оно служит отправной точкой.

ВАЖНО: Очень сложный и редко охватываемый аспект - это способ проверки подлинности форм в REST API. Отдельные запросы на вход, хранилище файлов cookie и т.д.

Ответ 1

Хотя я обернул множество веб-сервисов в OOP-ish, мне трудно найти хороший ответ на ваш вопрос.

Несколько примеров API Yahoo можно найти здесь: http://curlobjects.com/trac/browser/trunk/lib/YahooApi

1 Интерпретация кодов ошибок HTTP и ошибок протокола фильтрации из API ошибки.

В моем базовом классе http есть обратный вызов ошибки HTTP, который можно переопределить.

2 Построение запросов на основе URL-адресов, возможно с учетом соответствия шаблонов и замена токена.

Я предпочитаю конкатенацию строк.

4 Как сопоставить модель OO с моделью REST. Некоторые запросы удовлетворяют статическим способы, например. получение списков и другие висят посередине между статический и экземпляр, возможно, простой шаблон поставщика со всеми статическими методы?

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

Если у вас есть более конкретные вопросы, касающиеся форм входа, куки файлов и т.д., я был бы рад ответить на них.

Edit:

HttpWebRequest был упомянут, и я предполагаю, что вам нужно установить свойство ClientCertificate и правильно использовать SSL, или вы можете игнорировать все ошибки SLL с помощью CertificatePolicy.