Интернализация концепций REST API

Question

Мне трудно что-то обдумать, и я был бы признателен за чтение материалов по этой концепции.

Я пишу приложение, которое в значительной степени зависит от предоставления вызовов API через схему URI. example.com/company/user/123123. Имеет смысл взять строку URI и преобразовать ее в действие.

Но я запутался в том, что взял этот процесс и использовал его в структуре MVC. Я строю звонки, используя модели или библиотеку? Моя цель - сделать что-то вроде $ this-> company-> user (12311), чтобы у меня была возможность использовать функции API как снаружи, так и внутри.

Кроме того, как сделать эту функцию доступной, не раскрывая основной код?

Answer 1

Одна из самых больших проблем со словом API заключается в том, что он не делает различий между тем, когда вы делаете локальные вызовы в процессе и когда вы делаете удаленные вызовы. Это суть стиля RPC, использующего одну и ту же программную модель независимо от того, где существует код для выполнения.

REST явно предназначен для выполнения распределенных вычислений и оптимизирован для этих сценариев. Попытка использовать интерфейс RESTful в качестве локального API может привести к очень неэффективному результату.

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

Чтобы ответить на ваш вопрос более конкретно, я использую подход MVC для раскрытия ресурсов в моей системе. Модель - это ресурс, а представление - это представление. Ключом к созданию системы RESTful является выявление связей между вашими моделями. Эти ссылки отображаются в представлении в виде встроенных ссылок. Кроме того, учтите, что ваши модели должны быть больше похожи на презентационные модели , чем на доменные модели, поскольку интерфейс RESTful больше относится к представлению сценариев использования системы, чем к представлению модели домена.