2016-04-20 8 views
0

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

{ 
    "id": 26, 
    "email": "[email protected]", 
    "firstName": "Tommy", 
    "lastName": "Richards", 
    "photoUrl": null, 
    "userAddress": [ 
     { 
      "id": 8, 
      "type": "home", 
      "addressLine1": "DP Road", 
      "addressLine2": "Main Street", 
      "city": "Los Angel", 
      "state": "CA", 
      "country": "USA", 
      "postalCode":915890 
     }, 
     { 
      "id": 25, 
      "type": "office", 
      "addressLine1": "Dr Red Road", 
      "addressLine2": null, 
      "city": "SA", 
      "state": "CA", 
      "country": "USA", 
      "postalCode":918950 
     } 
    ] 
} 

Где в идеале должен проверить тип адреса [в моем случае дома или офиса] в передней части [веб-сайт или телефон] или назад конец [сторона сервера] или обе стороны? Какой подход подходит для проверки типа адреса? Если мы проверим его на стороне сервера, что вызовет любую проблему с производительностью?

Примечание. - Если разработчик передает любую строку, тип адреса подобной строки пропуска будет создан в БД.

+1

ВСЕГДА санируйте и проверяйте введенные пользователем данные на сервере. Любая проверка на лицевой стороне предназначена исключительно для улучшения пользовательского интерфейса. На большинстве веб-сайтов вам нравится использовать данные проверки на передней панели, а затем снова после того, как он достигает сервера. – WillardSolutions

ответ

0

Причины Front End проверки: Проверка на сервере, пользователь должен ждать ответа в случае недостоверных данных.

Проверка валидации: чтобы убедиться, что данные не могут быть изменены злоумышленником.

Validate @database end: Как и Mongoose, предусмотрена встроенная и пользовательская проверка.

В соответствии с требованием мы должны перекрестно проверять данные перед обновлением профиля пользователя.

1

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

Вдобавок к этому, на некоторых (если не на всех) случаях полезно делать некоторые проверки на лицевой стороне, одна из причин заключается в том, что если у вас есть запрос, который, как вы знаете, спасти себя неприятности и проверить его, прежде чем сделать дорогостоящую просьбой об

+0

Если мы проверяем тип адреса на задней стороне, что вызовет любую проблему с производительностью или займет больше времени для ответа? –

+0

Это будет, но это может быть очень быстрая проверка. С другой стороны, не проверка и получение отказа от вставки в db может быть медленнее (не говоря уже о возможности вставки плохих неутвержденных данных в db) –

+0

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