API?
- 입력과 출력 -> 함수와 비슷하다
- 규격에 맞는 입력이 주어진다면 규격에 알맞은 출력값을 뽑아주는것
- 만약 값이 다르다면 값이 다르단것을 알려줘서 에러상황임을 인지시켜준다.
Rest?
HTTP URI를통해 명시하며 HTTP Method를 사용하여 행위를 정하는것
- HTTP표준만 있다면 어떤 기술이든지 사용이 가능하다
- 클라이언트 - 서버의 구조를 가지고 있따.
- 서버는 클라이언트의 상황을 고려하지 않고 구현이 가능하다
- URI와 Method자체가 의미가 존재한다
- 클라이언트는 최상위라 계층이 불가능하지만 서버는 로드밸런싱,암호화 및 프록시등 중간 경유를 자유롭게 사용이 가능하다.
What is RESTful?
- uri는 리소스를 표현해야한다
- 절대로 행위에대한 글자가 들어가면 안된다.
- 리소스명은 명사를 사용하며 대문자를 쓰지 않는다.
- 행위는 Http Method를 통해 표현한다
- GET은 조회
- POST는 생성
- PUT,PATCH는 업데이트
- DELETE는 삭제
- 요청에대한 응답의 상태코드가 명확해야한다.
- 2xx : 200,201등 성공에대한 응답
- 3xx : 리다이렉션 (성공했지만 추가적인 작업이 필요한 경우)
- 4xx : 클라이언트측 에러
- 5xx : 서버측 에러
왜 grpahql이 만들어졋는가
- 끝없는 엔드포인트
- 서비스가 커질수록 엔드포인트가 늘어나며 감당이 힘들어진다
- 엔드포인트 변경시 프론트, 백 둘다 수정이 필요함
- api docs의 명세 관리가 어렵다
- over-fetching ( 불필요한 정보까지 받는 문제)
- under-ferching ( 요청 한것의 정보를 받기위한 요청 )
장점
- 수많은 엔드포인트들을 한개로 사용이 가능하다
- 두개로 통합된 method로 관리한다
- GET은 Query
- POST,PUT,DELETE 등 데이터의 변화가 일어난다면 Mutation을 사용한디.
- 자체적인 api docs를 지원하는 apollo server
- GraphQL은 Apollo Client / Server를 사용하여 API를 통신하며 api에대한 명세를 자동으로 갱신하며 자체적인 테스팅툴로 api를 테스트가 가능하다
- 원하는 데이터만 골라 받아올 수 잇어 Over-Fetching에서 자유롭다
단점
- http 캐싱이 불가능하다
- 기존 REST API에서도 간단한 쿼리 및 스키마 정의가 가능하여 굳이 쓸필요 까지는 없다
- 하지만 모든 기능을 통일된 방식으로 사용한 GraphQL이 있어 두개의 장단점을 생각해 만드는것이 좋다.
