Прикладное приложение, которое я пишу, должно использовать REST API от LinkedIn . В настоящее время у меня есть основной код потока OAuth, работающий с использованием Hammock .
Но я еще не храню токены доступа OAuth. Я посмотрел на DotNetOpenAuth и пришел к выводу, что его использование сделает поток более читабельным.
Чего я пока не понимаю, так это как DotNetOpenAuth и Hammock будут использоваться вместе в потребительском приложении, если вообще будут использоваться.
Я думаю, Я могу захотеть использовать стратегию десериализации Hammock, когда в следующий раз начну использовать реальный API групп. Я не уверен, имеет ли смысл использовать DotNetOpenAuth для чего-либо еще , чем поток OAuth. (Возможно, только для проверки того, что токены все еще действительны, если пользователь возвращается в приложение?)
Кто-нибудь имеет опыт использования обоих (в одном приложении), предпочитает одно другому, или знает ситуации, когда вам могут понадобиться оба для выполнения задач, связанных с OAuth / REST?
PS. Мне известно о LinkedIn Developer Toolkit . С тех пор я решил не использовать это, но он не поддерживает API групп LinkedIn , и он не обновлялся в течение года.