REST 하다?

REST API 에서 REST는 Representational State Transfer 의 약자로 소프트웨어 프로그램 아키텍처의 한 형식이다. 웹에 존재하는 자원에 고유한 URI를 부여하여 자원의 주소를 지정하는 방법론, 규칙을 의미한다.

• 즉, 자원을 이름 (자원의 표현) 으로 구분하여 해당 자원의 상태 (정보)를 주고 받는 모든 것을 의미한다.
• 월드 와이드 웹 (WWW) 과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
• REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

아키텍쳐 종류에는

- Graphql
- SOAP
- GRPC
- REST

RESTful APIs 개발하는 가장 큰 이유는 Client Side를 정형화된 플랫폼이 아닌 모바일, PC, 어플리케이션 등 플랫폼에 제약을 두지 않는 것을 목표로 했기 때문이다.

Reprensentational State Transfer

• HTTP URI를 통해 자원을 명시하고, HTTP Method (POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD OPERATION을 적용하는 것을 의미
• 즉, REST는 자원 기반의 구조 (ROA: Resource Oriented Architecture) 설계의 중심에 Resoure가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미.
• 웹의 모든 자원에 고유한 ID인 HTTP URI 를 부여한다.

SOAP vs REST vs Graphql

SOAP는 XML 형식 을 따르며 XML은 가독성이 떨어지며 확장성이 떨어진다.

REST는 JSON 형태를 따르며, key&value 형태로 XML에 비해 명시적이다. 훨씬 부합한 형태.
URI적 분기가 끊임없이 이어진다.

GraphQL은 페이스북에서 만든 쿼리 언어로 REST API는 URL, METHOD등을 조합하기 때문에 다양한 Endpoint가 존재한다. 반면, gql은 단 하나의 Endpoint가 존재한다. 또한, gql API에서는 불러오는 데이터의 종류를 쿼리 조합을 통해서 결정한다. 예를 들면, REST API에서는 각 Endpoint마다 데이터베이스 SQL 쿼리가 달라지는 반면, gql API는 gql 스키마의 타입마다 데이터베이스 SQL 쿼리가 달라진다.

이점 : 별도의 uri 분기 없이 요청하는 값으로 중첩해서 요청 가능하다.

GraphQL은 완전히 이해 못한 상태에서는 어려우며 진입장벽이 높아 입문용으로는 어렵다!

클라이언트 → Rest API → 데이터베이스 - 리소스

클라이언트 → Rest API 에서 CRUD 이중에 R에 해당되는 메소드를 정해서 그 메소드에 대한 목적어, 대상을 설정해서 원하는 정보를 긁어온다.

장점: self-descriptiveness, 그 자체만으로도 API의 목적이 쉽게 이해된다.

하지만 이 REST API를 개발하다보면 HTTP의 Response 규약을 지키지 않고 본인들이 만들어넨 JSON 컨벤션으로 응답하는 경우를 많이 확인 할 수 있는데 그것은 옳지 않은 개발 방향이다. 왜냐하면 Client Side가 정형화 되어있지 않은 환경에서 개발 속도를 저하하는 가장 큰 이유는 표준을 지키지 않았기 때문이다.

단점: 너무나 쉬운 접근과 유연성으로 표준 규약이 없어서 안티패턴으로 작성되는 경우가 흔하다.

안티패턴: 실제 많이 사용되는 패턴이지만 비효율적인 패턴

ex) 대문자 사용이 기피되지만 내 코드상에서 편하게 하기위해서 대문자를 쓴다.

REST ful API 설계 규칙

• URI 정보를 명확하게 표현해야 한다.
  • resource는 명사를 사용한다.
  • ex) GET /user/1 → GET/users/1
    (단수보다는 복수 형태로 더 많이 사용한다. 유도리 있게 사용하자.)
• resource에 대한 행위를 http Method 로 표현하다.
  • URI에 포함되서는 안된다.
  • ex) GET delete/user/1 → Delete/users/1
  • URI에 동사가 포함되서는 안된다.
  • ex) GET user/show/1 → GET/users/1
  • ex) POST insert/user/2 → POST /users/2
• resource 사이에 연관 관계가 있는 경우
  • /리소스/고유ID/관계 있는 리소스
  • ex) GET/users/{user_id}/profile
• 파일의 경우 페이로드의 포맷을 나타내기 위한 확장자를 URI에 포함시키지 않는다.
  • ex) GET user/1/profile-photo.jpg
  • ex) GET user/1/profile-photo
  • 페이로드 포맷은 headers에 accept를 사용한다. content의 type을 정할 수 있다.
• • 사용
• 대문자 사용금지 _ 사용금지 띄어쓰기는 - 로

1. 자원에 대한 명시 → 어떤 내용인지 가늠이 되지 않는다.
   1. GET http://10.58.4.1:8000/product
   2. 어떤 단일 상품에 대한 상세 페이지
2. GET http://10.58.4.1:8000/products
   1. 복수로 표현
   2. 데이터적 관점에서는 어떤 곳에서 어떤 상품에 대한 호출 신호를 받아야하는 uri를 짜야한다.
   3. 페이지별로가 아닌, 데이터 관점
3. GET http://10.58.4.1:8000/product
   1. find, 동사 사용 금지
   2. get에서 이미 동사에 대한 행위가 선언
4. POST 가 이미 선언, add가 들어갈 필요가 없음
5. http://10.58.4.1:8000/product1/reviews
6. 8000products?name=
   쿼리스트링 써야하는 경우임.