입문자뿐만 아니라 중급자에게도 자신 있게 이 책을 권한다. 이 책은 PHP 언어 또는 웹 프로그래밍을 한 번도 접해 보지 않은 독자도 읽을 수 있도록 부록에서 입문 지식을 제공하고 있다. 다른 프레임워크를 사용해 보신 독자라면 라라벨을 더욱 쉽게 배울 수 있으며, 반대로 라라벨을 익힌 사용자는 익스프레스, 레일즈, 장고 등을 학습하는 것이 수월할 것이다. API 서버를 개발하는 실전 프로젝트에서는 HTTP 스펙 등 고급 주제도 다루므로 여러 층의 독자에게 도움이 될 거라 장담한다. _xiv

라라벨은 민감한 설정 정보를 은닉하거나 애플리케이션 동작에 필요한 전역 환경 변수를 쉽게 변경할 수 있는 방법을 제공한다. config 디렉터리 아래에 연관 배열(associative array)을 반환하는 파일을 만들면 애플리케이션 어디서든 config('파일.키');로 설정값을 읽을 수 있다. _12p

라라벨은 완성품에 가까운 사용자 인증 기능을 포함하고 있다. 사람마다 기성품과 맞춤 양복 사이에서 호불호가 갈리듯이, 남이 짠 사용자 인증 로직을 이해하여 고치기란 쉽지 않기 때문에 라라벨 내장 사용자 인증도 호불호가 갈린다. 이러한 라라벨 팀의 오지랖이 입문자 또는 프로토타입을 만드려는 사람들에게는 많은 도움이 된다. _81p

소프트웨어 개발을 집 짓는 일에 비유해 보자. 집 한 채를 지으려면 벽돌, 문짝, 창틀과 창문, 지붕 등의 각종 부품이 필요하다. 의존성을 바로 이 부품들에 빗댈 수 있다. 가령 문짝이란 부품이 하나 빠졌다면, 이 집이 겉으로는 멀쩡할지 몰라도 문짝이 필요한 상황에서는 심각한 문제를 일으킨다. 잠시 소프트웨어로 돌아오면, 우리 코드에서 foo()를 호출했는데 이 함수가 없는 것과 같은 것이다. 이때 우리 코드는 foo()에 의존한다고 말할 수 있다. _154p

사용자의 비밀번호를 테이블에 저장할 때 사용하는 bcrypt() 해시는 복호화가 불가능하므로 관리자조차도 사용자의 비밀번호를 알 수 없다. 참고로 우리가 가진 사용자 정보는 이름과 이메일이 전부다. 이 조합은 다른 사람도 알 수 있는 값이라, 이 정보만 가지고 비밀번호를 변경하도록 허용할 수는 없다. 무엇인가 사용자 신분을 확인할 수 있는 방법이 필요하다. 이 경우 가입 확인에서 실시했듯이 메일을 보내 본인을 확인하는 방법을 응용할 수 있다. _229p

물론, 이것이 완벽한 방법이라 할 수는 없다. 왜냐하면 토큰을 요청할 때는 사용자 인증 정보를 폼 데이터 또는 JSON 형태의 평문으로 서버에 전달해야 하기 때문이다. 웹 페이지를 사용할 때도 로그인 폼을 통해 인증 정보를 평문으로 전달하기 때문에(인증되면 암호화된 쿠키로 로그인 유지) JWT는 웹 페이지와 같은 보안 수준이라 할 수 있다. 그럼에도 HTTP 기본 인증보다는 낫다. 보완책은 HTTPS를 사용하여 암호화된 데이터를 주고받는 것이다. HTTPS를 적용하면, 패킷 스니퍼는 물론이고 네트워크 프록시도 목적지만 제외하고 헤더와 본문을 전혀 읽을 수 없다.