라라벨에서 API를 작성하는 방법에 대해 알아보는 내용.
RESTful API란?
REST(Represntational State Transfer) API란 SPA(SIngle Page Application) 또는 기타 클라이언트에서 데이터를 요청하고 처리 및 가공할 수 있도록 서버에 리소스를 요청하는 방법 중 하나이며, 클라이언트는 REST API가 구현된 서버에 요청하면 JSON(Javascript Object Notation) 으로 처리하는 것이 일반적이다.
기존에는 XML도 사용했지만 이제는 JSON으로만 반환하는 경우가 많아 라라벨에서도 JSON을 반환하는 것을 주력으로 한다.
클라이언트의 요청에 따른 응답으로 JSON이라는 포맷을 빌려서 리소스를 묘사(Representational)하여 현재의 상태(State)를 클라이언트에 전달(Transfer)한다. 여기서 상태라함은 현재 리소스의 현황이라고 이해하는 것이 쉽다.
REST API는 표준이 아닌 API 아키텍처 스타일이다. 따라서 꼭 지켜야 하는 의무는 아니지만 통상적으로 권장되는 스타일 가이드가 존재하는데 이러한 스타일 가이드를 잘 지켜서 ful하게 만드는 것이 RESTful API이다.
URI
RESTful API에는 권장되는 몇 가지 URI 규칙이 존재한다. 이는 서비스마다 다를 수 있지만, URI는 해당 API가 RESTful한지 평가하는 가장 기본이 되는 요소이다.
중첩된 리소스를 포함할 때는 GET /blogs/hello-world/posts/1고 같이 표현할 수 있고, blogs와 같이 복수형으로 쓰인 부분은 컬렉션(Collection) posts/{post}와 같이 표현하며, URL 파라미터로 쓰이는 부분은 Document라는 용어를 사용한다.
HTTP 메서드
HTTP 메서드를 REST API 스타일 가이드에 따라 사용하는 것은 URI 규칙과 마찬가지로 가장 중요시되는 규칙 중 하나라고 볼 수 있다. 대표적으로 자원을 요청하는 GET, 생성하는 POST, 수정하는 PUT/PATCH, 삭제하는 DELETE가 있다.
HTTP HEADER
헤더 설정은 필수는 아니지만 리소스의 위치를 표현하는 Content-Location, application/json과 같이 자원표현 포맷을 의미하는 Content-type, 그리고 너무 잦은 리소스 요청으로 Too many Re-quests와 함께 첨부하는 Retry-After가 있다.
HTTML 상태코드
RESTful 하지 않은 API의 경우 상태코드는 200을 던지는데 정작 JSON에 포함된 staues에는 다른 코드를 표현하는 경우가 있다.
200번대 상태코드는 요청에 대한 성공, 400번대는 서버 에러를 제외한 에러, 500번대는 서버 에러를 의미한다.
HATEOAS
HATEOAS(Hypermedia as the Engine of Application State)는 응답을 던질 때 프론트엔드에서 해당 자원과 관련된 정보도 알 수 있도록 각종 하이퍼미디어, 즉, Links를 첨부하자는 이야기다.
버저닝
API 버저닝은 URL, Accept, Accept-version을 사용하는 버저닝 방법이 있다.
버저닝 같은 경우 일반적으로 웹 어플리케이션과는 별개로 API 프로젝트로 분리하여 깃 브랜치로 관리하는 것이 더 나은 방법이다.
라라벨 생텀
RESTful API는 무상태(Stateless)를 기본으로 간주한다. 상태가 없다는 뜻은 서버에 사용자가 상태를 유지하기 위한 세션과 데이터가 없다는 뜻이고, 클라이언트에서는 세션 쿠기가 아니라 API토큰을 가지고 있다는 뜻이다. API 토큰을 사용하면 세션과 쿠키를 기반으로 관리되는 것이 아니므로 클라이언트가 꼭 웹 브라우저가 아니더라도 사용자의 인증을 처리할 수 있다.
라라벨 생텀은 가벼운 API 토큰 기반 인증을 제공하여, 사용자가 스스로 API 토큰을 만들고 관리할 수 있도록 처리할 수 있다.
설치법으로는 Laravel 10.x 프로젝트라면 기본적으로 설치가 포함되어 있다. 설치되어 있지 않다면 conposer를 통해 설치할 수 있다.
$ composer require laravel/sanctumJWT(Json Web Token)인증
JWT는 라라벨 생텀처럼 토큰을 사용하고 RESTful API와 같은 무상태 환경에서 사용되며, 헤더 또한 Authorization을 사용하는데 PAT(Personal Access Token)인 라라벨 생텀의 토큰과는 다른 점이 있다.
JWT를 사용할 때는 personal_access_tokens 같은 별도의 테이블이 존재하지 않는다. 즉, 서버에 저장하는 않는다.
JWT는 토큰에서 정보를 자체적으로 가지고 있는 자기포함(Self-Contained)라는 특성을 가지고 있다. 토큰이 자체적으로 정보를 가지고 있다는 것은 저장하고 있는 정보가 많으면 토큰이 커질 수도 있다는 것을 의미하고, 서버의 부담을 줄여주는 것과 동시에 토큰에서 자체적인 보안 요소를 탑재하고 있음을 의미한다. JWT의 구조는 Header, Payload, Signature로 구성된다.
Header에는 JWT에서 사용할 타입과 해시 알고리즘의 종류가 담겨있다.
Payload는 서버에서 첨부한 사용자의 정보와 데이터가 담겨있다. 즉, 데이터 자체는 암호화되거나 보호되지 않고 외부에 노출되어 있다.
Siganature에는 Header, Payload를 Base64 URL-safe Encode한 이후 Header에 명시된 해시함수를 적용하고 Secret Key로 서명한 전자서명이 담겨있다.
