2017-02-15 3 views
4

Я создал API, который возвращает json в Laravel. (маршруты/api.php)Вы можете иметь свой API и есть (потреблять) его в Laravel?

Теперь я хочу, чтобы потреблять указанный API в моей web -side проекта (маршруты/web.php (в том числе промежуточного программного обеспечения), лезвие видом и т.д.).

Текущее решение, что у меня есть что-то вроде этого:

public function register(Request $request) { 
    // password1 == password2 etc (form logic/validation) 
    $internal_request = Request::create($this->base_api_url . 'register', 'POST'); 
    $internal_request->replace($request->input()); 
    $response = Route::dispatch($internal_request); 
} 

Какие «вперед» просьба к апи коллеге моему апи, если форма является действительным. Но у меня такое чувство, что это не самая лучшая практика или умная. Другие маршруты, кроме login и register, используют токен api, хранящийся в сеансе для совершения вызовов. они добавляют токен «x-token» в качестве заголовка к $internal_request. Лучше ли это делать в промежуточном программном обеспечении? Есть ли какой-нибудь пример лучшей реализации где-нибудь?

Мой API имеет метод так:

POST api/register Что проверить, существуют ли необходимые поля и имеют rigt формат (валидация)

и мой веб-маршрут имеет /register

Это будет сначала проверьте, совпадают ли пароли с входами проверки пароля (pass1 == pass2) и затем передают их эквиваленту api.

So web должно быть superset (валидация) api.

+0

Фокус на единой ответственности, то вынесем общую работу. Web, CLI и API отвечают за отмену и проверку ввода. После удовлетворения ввода, они затем передают проверенный вход в общую службу, которая выполняет требуемую задачу. Наконец, они берут результат этой общей службы и направляют ее обратно пользователю. Loopback звонит, как эта работа, но они избыточны, потому что marshalling/unmarshalling происходит дважды. Это также делает тестирование более сложным, чем необходимо, поскольку вы в конечном итоге полагаетесь на интеграционное тестирование и часто тестируете одни и те же пути снова и снова. – bishop

+0

@bishop Да, я думал о том, чтобы делать больше внутри модели и меньше в контроллерах. Таким образом, модель = единая ответственность. Но есть ли какой-то жесткий способ? –

+0

Нет, нет жесткого пути из-за TIMTOWTDI. Я согласен с тем, что продвижение большинства работ на уровень сервиса модели - это путь. Но я подчеркиваю часть * service *: множество классов типа модели, работающих с различными частями общей проблемы преобразования данных, а не с несколькими гигантскими моделями, которые делают слишком много. – bishop

ответ

1

Я думаю, что я буду делать это так:

  • обнаружить в, если мы контроллера обрабатывать запрос API или веб-запрос
  • определять учетные данные (токен или сеанс связи)
  • делать логику формы, если сеть
  • сделать апи логику в обеих ситуациях
  • создать вид или JSON ответ соответственно
  • все в том же контроллере
1

Насколько я понимаю ваш вопрос, вы хотите применить ту же логику к api и веб-запросам, и вы можете просто хотеть (a) проверить форму для веб-запроса и/или (b) обернуть ответ в json для запроса API.

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

в маршрутах/web.php, добавить Route::post('/register', '[email protected]) ; `

и в маршрутах/api.php, добавьте Route::post('/register', '[email protected])`

Так в конце концов оба запроса (API/регистрация и/регистр) попал в тот же контроллер и метод.

Теперь в контроллере можно выполнить дополнительные действия, в зависимости от желания выглядеть примерно так:

public function register(Request $request) { 
    if(!$request->expectsJson()) { // you may want to swap this with $request->isJson() depending on the HTTP headers for your app 
     $this->validateWebRegistration($request); // your validation logic specific to web requests here 
    } 

    // common logic here (including validation); store result as $result 

    if($request->expectsJson()) { // based on HTTP headers as above 
     return response()->json($result); 
    } else { 
     return view('register', $result); 
    } 
} 
+0

Я отредактирую свой вопрос, чтобы вы поняли разницу между ними лучше:) –

+0

Я отредактировал свой ответ на основе вашего обновленного вопроса. Однако я не понял первую часть вашего вопроса. Что такое 'x-token'? Вы имеете в виду токен CSRF? – Paras

+0

X-token - это мой токен api, который я генерирую на api/login и должен быть отправлен как заголовок с каждым запросом. –

 Смежные вопросы

  • Нет связанных вопросов^_^