1. RESTful
-
REST는 어떤 데이터를 원하는 지 설명하고, 구분하여 자원의 상태를 주고 받는 모든 것을 의미한다.
-
통신을 잘 하기위한 통신 규칙
-
프론트엔드가 어떤 데이터의 정보를 가져오고자 요청하는 것 (/users)
-
프론트엔드가 1번 음료의 정보를 가져오고자 요청하는 것(/bevergeges/1)
-
프론트엔드가 101번 유저의 정보를 가져오고자 요청하는 것(/users/101)
-
HTTP URI를 통해 자원(데이터 베이스에 있는 데이터)을 명시하고, HTTP Method(POST, GET, DELETE)를 통해 해당 자원에 대한 요청을 처리하도록 설계된 아키텍쳐를 의미한다.
ex 1) 아이디가 1번인 유저 정보를 달라고 요청하는 request 메세지?
- GET
ex 2) 이름이 '홍길동' 인 새로운 유저정보를 생성 요청하는 request 메세지? - POST
REST API의 장단점
- 장점 : self-desctiptivenss
-> RESTful API는 그 자체만으로도 API의 목적이 쉽게 이해가 됨. - 단점 : 표준 규약이 없어 '안티 패턴으로 작성되는 경우가 흔함 (EX. /products/all)'
2. RESTful API 설계 원칙
2-1. Uniform Interface
-
구성요소(클라이언트와 서버 등) 사이의 인터페이스는 일관(uniform) 되어야 한다는 원칙
-> 플랫폼에 무관하며, 특정 언어나 기술에 종속받지 않는 특징을 의미한다. -
URI는 동사를 제외한 명사로 구성
-> [GET] /find/users/1 -> [GET] /users/1 -
Resource에 대한 행위를 HTTP method만으로 표현
-> [POST] /post/reviews -> [POST] /reviews -
Resource 사이에 연관 관계 및 계층 관계가 있는 경우
/사용
-> [GET] /users/{user_id}/posts -
URI 마지막 문자로
/를 포함하지 않음.
-> [GET] /users/portfoliso/ -> [GET] /users/portfolios -
URI가 길어지는 경우
-를 사용하여 가독성을 높임
-> [GET]/users/1/ordered-items -
파일 확장자는 URI에 포함시키지 않고 파일의 확장자는 headers에 포함
->[GET] /users/1/profile-photo
2-2. 나머지 원칙들
- Client - Server
- 구조를 단순화 시키고 작은 단위로 분리함으로써 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해야함. - Stateless
- 각 요청 간 클라이언트의 Context가 서버에 저장되어서는 안됨. - Cacheable
- 클라이언트는 요청에 관한 응답을 따로 저장함으로써 추후에 재사용이 가능하게 해야함. - Layered System
- 클라이언트는 서버에 직접 연결되었는지, 또는 중간 서버를 통해 연결 되었는지를 알 수 없음. - Code on demand
- 서버가 네트워크를 통해 클라이언트에 전달한 javascript 등과 같은 프로그램들은 그 자체로 실행이 될 수 있어야 함.
3. Path Parameter
- 서로 다른 데이터지만 자원의 종류는 동일할 떄 path parameter를 이용하여 RESTful한 API 구성 가능.
4. Query parameter
-
백엔드가 조건문에 대한 것을 설정 후 공유해주고 프론트는 쿼리 파라미터를 사용해 그 조건을 보내면 백엔드에서 해당되는 것 (sort 등) 에 따라 정렬을 진행하고 데이터를 보내줌
-
필요한 조건을 요청에 따라 데이터를 선택적으로 처리할 수 있는 통일된 API 구성할 떄 사용하는 매개변수.
유일한 값을 식별하기 위한 용도가 아닌옵션을 줄 때 사용
5. GraphQL
-
REST로 요청했을 때, 모바일과 웹에서 각자 요청하는 키/벨류 값이 다른 경우가 있는데 그게 불편했던 Facebook 에서 GraphQL 을 만들었고, GraphQL을 사용하면 모든 데이터를 백엔드가 가지고 있으면 프론트는 원하는 데이터를 하나하나 빼서 가져올 수 있다.
-
필터링, 정렬, 페이지네이션, 검색등의 경우에서 사용한다.
