[1] Rest API

RestAPI(Representational State Transfer API)를 restful 한 api

• sql 쿼리 언어를 사용한다.
• 엔드포인트가 1개 이다.
• 백엔드에서 쿼리언어를 작성한다.
• restful한 방식은 정해진 규칙이 아니라 개발자들 사이에서 암묵적으로 정해진 약속
• restful한 방식은 똑같은 url로 요청을 날리지만 http메소드(get, post, delete, put)으로 엔드포인트를 구분하낟.

(1) 장점

1. http 프로토콜 환경이라면 쉽게 사용이 가능하다.
2. api를 통해서 서버와 클라이언트를 분리해서 쉽게 송수신이 가능하다.
3. 헤더부분에 uri처리 메소드를 명시하기 쉽다.
4. 현재(2022년) open api는 대다수가 rest api방식으로 되어있어서 아직 gql 방식으로 서비스를 하기에는 문제가 있다.
5. 다중 계층으로 처리해서 로드밸런싱, 보안, 공유캐시, 암호화 등등을 처리해서 보안과 확장성에 좋다.
6. 송수신을 하는 목적과 결과가 명확하게 정해져있다.
7. 캐시 기능을 사용할 수 있다. (사용을 해보지는 않아서 잘은 모르겠다.)
8. 각각의 요청을 독립적으로 인식하고 처리한다.

(2) 단점

1. 사용할 수 있는 메소드가 한정적이다.
2. 통신방식이 http 방식에 한정이 된다

(3) 규칙

명확하게 정해진 규칙은 존재하지 않는다. 다만 서로 많이 사용하고 암묵적으로 정해진 방식에 의해서 설계한다.

1. uri에는 명사와 소문자, "-" 만을 이용해서 작성한다.
2. 마지막에 /를 넣지 않는다.
3. 파일 확장자는 넣지 않는다.
4. uri만을 보고 어떤 요소를 삭제하는지와 같은 경로를 만들지 않는다. /update-user-password
5. 같은 경로이지만 http 메소드명만으로 구분을 하여야 한다.

ex.com , Create
ex.com, Read
ex.com, Update
ex.com, Delete
위의 4개는 요청하는 uri는 모두 같지만 백엔드에서는 http메소드를 이용하여 전부 다른 엔드포인트로 구성을해야한다.

[2] GraphQL

페이스북에서 만든 쿼리 언어

• sql이 아닌 gql 쿼리 언어를 사용한다.
• sql과 달리 gql은 클라이언트(프론트엔드)쪽에서 쿼리를 작성해서 가져온다.

(1) 장점

1. 데이터베이스에서 효율적으로 데이터를 가져올 수 있다.
2. 일반적으로 L7 Http post와 웹소켓 프로토콜을 이용해서 송수신한다.
3. Rest APi는 get,post,put,delete 4개의 방식으로 통신을 하였다면 graphql은 query(get)와 mutation(post, put, delete) 2가지만을 이용해서 사용한다.
4. 인트로스펙션(서버에 정의된 스키마의 정보를 실시간으로 공유하는 기능)을 지원해서 Rest API와 같이 API 명세서를 작성하지 않아도 된다는 점이다. ( RestAPi에서는 swaager라는 기능이 존재한다. )
5. 엔드포인트 1개로 여러개의 작업을 처리할 수 있다.
6. Rest API에서 발생하는 under-fetching이나 over-fetching에 대해서 유연하게 대처할 수 있다. (개인적으로는 Rest API를 사용할 때 필요한 정보만을 주고 받아서 그렇게 손실이 많이 발생하지는 않는다고 생각한다.)

(2) 단점

1. 클라이언트(프론트엔드)에서 리졸버(쿼리를 실행)를 직접 구현해야 한다. (프론트엔드의 업무량 증가)
2. 재귀적인 쿼리가 불가능하다. ( 백엔드가 graphQL에서는어떻게 되있는지 몰라서 잘은 모르겠지만 RestAPI에서는 백엔드에서 요청받은 데이터를 처리할 수 있는 로직을 작성가능하지만 graphql에서는 데이터를 보내고 다시 클라이언트쪽에서 판단을 해서 쿼리를 다시 날려야 하는 것을 의미한다고 생각한다.)