REST API-запрос должен быть на стороне клиента или сервера?

Question

В качестве примера:

Существует API проверки результатов экзамена, и есть другое веб-приложение, которое использует api как услугу. В соответствии с этим ответ API (если успех) пользователь может войти на сайт или не

Для этого у меня есть проблема с основами,
я пришел с двумя вариантами (Там может быть много :) любой хороший принимается!)

01). Вызовите API, используя запрос AJAX с перекрестным доменом, и в соответствии с ответом. Отправить еще один запрос на веб-приложение, сценарий сервера и создать сеанс

$.get("http://api.resultval.com/v1/", 
    {index_no : no,subject : sub,grade : grade},function(response_msg){ 
     obj = JSON.parse(response_msg); 
     if(obj.msg.valid){ 
     // results validated marked as validated result on user cv 
     } 
    } 
); 

02). Вместо отправки запроса AJAX для API отправки пользовательских вставленные результатов на стороне сервера и на стороне сервера с помощью сценариев вызвать API с помощью жрать библиотека

$client = new \GuzzleHttp\Client(); 
      $response = $client->get('http://api.resultval.com/v1/'.Input::get('index_no').'/'.Input::get('subject').'/'.Input::get('grade')); 
      if($response->json()['msg']==='verified'){ 
      // results validated marked as validated result on user cv 
      } 

Каков наилучший подход? Как насчет безопасности? Я думаю, второй хороший! но я все еще думаю о том, есть ли способ сделать это на стороне клиента?

Answer 1

Рассмотрим реализацию вашего решения с использованием JWT:

JSON Web Токен (JWT) является компактным URL безопасным средством репрезентации требования должны быть переданы между двумя сторонами. Претензии в JWT кодируются как объект JSON, который с цифровой подписью с использованием JSON веб-Signature (JWS)

Answer 2

Я предпочел бы выбрать, чтобы сделать это на стороне сервера из следующих причин:

1. JavaScript могут быть изменены пользователем. Запросы Ajax могут быть токсичными из-за плохих изменений в JS-коде, пытающихся достичь нарушения безопасности.

2. На сервере ServerSide у вас есть гораздо лучшие возможности для регистрации вызовов, которые отправляются определенным пользователем и выполняют действия на основе результатов, поступающих с API. Возможно, в один прекрасный день вам придется делать дорогие операции на основе результатов, которые вы получаете.

3. Чем меньше пользователь знает, тем лучше. Ваши пользователи не должны знать, какие услуги вы вызываете. По крайней мере, они не знают API-адреса API и данные, которые вы отправляете в API напрямую (что было бы возможно с помощью developertools или снифферов трафика)

4. Вы не можете гарантировать безопасность возможного стороннего API, но вы можете использовать свои собственные системы. Если у пользователя будет возможность отслеживать API, который вы вызываете, с отправленными данными и точными URL-адресами, пользователь может попытаться атаковать этот API. Хотя вы не знаете, является ли API достаточно безопасным, чтобы противостоять такой атаке, вы можете знать, что ваша система делает это. Также вы можете мгновенно обновить свой проект, если происходит атака или нарушение безопасности. Вы не можете сказать, когда это произойдет в стороннем проекте. Я думаю, что это один из самых важных моментов!