Project 2 - 2일차 : [Restful API] 세션/ Path vs. Query parameter

앞으로는 restful api 엄격하게
add, create 가 들어가지 않게 리뷰해서 main branch에 들어가지 않게끔.
main branch에는 엄격하게 지켜져야 함

 

호출할 때, 프론트가 json body에 담아서 가져가는게 아니라,

프론트가 보낼 때부터, 나는 뭐가 필요해 라고 객체의 key value에 담아놓고 보내면,

백엔드가 필요한 데이터만 골라서 보내줌 (graphQL) 

---

RPI ; Representational State Transfer 

 

Rest = 규칙 

 

Restful api = 규칙을 잘 지킨 api 

통신을 잘 하기 위해 의사소통 규칙 

Http 통신은 statless 가 대표

 

상태(State)를 전달(Transfer)하는 것을 나타내는(Representation) 방법

“자원(=data)을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 것

 

여기서 client =  프론트엔드

 

'어떤 자원을 어떻게 하고 싶은지' 말해줘야 함

 

어떤 자원(data) = users, beverages/1

어떻게 = get/ put/ post (Method)

•  client가 'user'(무엇을)의 정보를 '가져와라'(어떻게) 요청 --> Get/user
•  client가 '1번 음료'(무엇을)의 정보를 '가져와라'(어떻게) 요청 --> Get/beverage/1
•  client가 '101번 user'(무엇을)의 정보를 '가져와라'(어떻게) 요청 --> Get/user/101 

 

HTTP URI (Uniform Resource Identifier) 통해서, 자원 (Resource) = Data 명시

HTTP Method ( Post, Get, Put, Delete) 통해, 해당 자원에 대한 요청을 처리하도록 설계된 아키텍쳐

 

EX.

get/users/1 (유저 아이디 1번 달라)  (프론트가 get/ 백엔드가 프론트에게 주는, )

Post /username 홍길동  (프론트가 post/ database에 insert해라, 그러면, 프론트가 백엔드에게 정보 주는)

---

 REST API의 장점: Self-descriptiveness

스스로 설명이 가능하다. RESTful API는 그 자체만으로도 API의 목적이 쉽게 이해가 되기 때문입니다.

---

RESTful API 설계 원칙

REST는 설계 규칙이므로, 일반적으로 널리 통용되는 규칙이 있습니다.

프로그램의 원활한 유지보수와, 개발자들 사이에서의 커뮤니케이션을 원활히 돕도록 만들어진 규칙들입니다.

1. Uniform Interface

통일하자. 

 

1-1. 구성요소 (client, server) -> 통일 (플랫폼에 무관, 특정언어/기술에 종속 받지 않음)

[GET] /delete/users/1 (x)	[DELETE] /users/1 (0)
[POST] /post/products (x)	[POST] /products (0)

 

1-2. URI는 동사 제외한 명사로 구성

요청을 진행할 대상(URI)는 자원이므로, 해당 자원을 정확하게 지칭하는 명사로 구성하는 것이 좋다.

ex. GET / find/ users/ 1 (x)

      GET / users/ 1 (0) 

[GET] /users/show/1 (x)	[GET] /users/1 (0)
[POST] /insert/user/2  (x)	[POST] /users/2 (0)

 

1-3. resoure (data) 행위를 HTTP method (get/post/ put / delete)으로만 표현 

   ex. find/users (x) 

 

1-4. resource (data) 사이 연관관계 및 계층 관계 있을 땐 '/' 사용 

 

/resource/고유 ID/연관 관계 있는 resource

ex) [GET] /users/{user_id}/profile  : 어떤 사용자의, 몇 번 포스팅을, 하고 싶다.

 

1-5. URI 마지막 문자는 / 붙이지 않음

(X)	(0)
[GET] /users/portfolios/	[GET] /users/portfolios

 

1-6. URI가 길어지면 dash(-) 사용 (언더바 보다는)  --> 가독성 

(X)	(0)
[GET] /users/1/ordered_items	[GET] /users/1/ordered-items

 

1-7. 파일 확장자는 URI에 포함시키지 않습니다.

 

       이때, payload에 포함되는 파일의 확장자는 headers에 포함됩니다.

BAD	GOOD
[GET] /users/1/profile-photo.jpg	[GET] /users/1/profile-photo

 

Response의 status code 종류

 

 나머지 원칙 

2. Client- Server

• 구조 단순화, 작은 단위 분리
• '클라이언트 (frontend)- 서버(backend)' 각 파트 독립적

Server (backend): 데이터를 저장하는 data storage part/ API를 제공하는 역할만 수행

Client (frontend) : 이를 활용하고 서비스를 구동하는 user interface를 분리/ 

                                  사용자 인증이나 context(세션, 로그인 정보 등)를 직접 관리

 

과거: client와 server가 명확히 분리되어 있지 않고,

서버에서 html,css를 모두 만들어서 사용자에게 제공

 

현재: client(프론트엔드)와 server(백엔드)에서 개발해야할 내용이 명확해졌기 때문에, 서로의 의존성이 줄어듦.

이는 각자 신경써야 하는 개발 분야가 달라졌음(관심사의 분리) -->  독립적인 개발이 가능

개별 부분의 발전에 있어 다른 부분이 영향을 주지 않는다는 장점

 

3. Stateless

상태에 대한 정보를 따로 저장하거나 관리하지 않는다

→ 매 요청은 독립적  (앞에 있는 요청을 뒤에 있는 요청이 기억할 수 없음) 

 

아까 요청을 했다고 해서 저장 하는 거 x ,

아까 요청을 했다고 해서 토큰 저장 x  --> 매번 요청할 때마다 보내야 함, 헤더에 보내야 하고. 

 

한 번 로그인한 정보를 서버에서 영원히 알고 있나?

REST에서는 X

 

API서버는 들어오는 요청만을 단순히 처리하고,

요청에 대한 결과를 서버에 따로 저장하지 않기 때문에,

 

이미 로그인을 했는지, 이미 주문을 했는지 server는 알지 못함.

 

• 서비스의 자유도가 높아지고,
• server에서 불필요한 정보를 관리하지 않음으로서 서비스 구현이 단순
• 코드의 가시성과 안정성이 확보
• 더 간편하게 확장될 수 있다

server가 세션 정보, 쿠키 정보 또한 별도로 저장하거나 관리하지 않기 때문에

client에서 상태 정보를 항상 전송해야 함 --> 따라서 통신 비용이 높아짐

 

4. Cachable

- 요청에 대한 ‘응답’을 저장해서 재사용 가능 

 

Stateless에서 통신 비용이 높아짐을 해결하기 위한 정책

 

client-server의 상호작용 제거하여 성능 향상, 확장성 보장

 

추가적인 기능을 생성하는 것이 아닌 기존 웹 표준을 사용 --> HTTP가 기본적으로 가지고 있는 캐시 정책을 사용할 수

 

 

요청에 대한 응답을 매번 갱신하는 것이 아니기 때문에,

캐시를 이용하여 데이터를 보여줄 경우 server측에서 업데이트된 데이터가 반영되지 않고,

캐시된 데이터를 보여줄 경우 신뢰성을 감소시킬 우려가 있습니다.

 

# 첫번째 요청
GET /v2/tasks/2
# Reponse
200 OK
Last-Modified: Sun, 03 Apr 2016 16:09:23 GMT

# 두번째 요청
GET /v2/tasks/2
If-Modified-Since: Sun, 03 Apr 2016 16:09:23 GMT
# Reponse
304 Not Modified

# 기존의 데이터를 그대로 사용한다(이건 구현에 따라서 달라질 수 있다)

 

5. Layered system 

• server가 1,2개인지 frontend는 알 수 없음 = client는 server에 직접 연결됏는지, 중간 서버를 통해 연결됏는지 알수 없음

통신은 여러 기능이 혼재

 

인터넷 규모의 요구 사항을 향상시키기 위해 레이어드 시스템을 지키며 설계

복잡한 여러 기능을 계층화, 한 기능씩 순차적으로 진행

 

레이어가 여러 층으로 구성,

특정 기능이 진행되는 동안은 해당 레이어 너머의 시스템을 확인할 수 없게 --> 시스템 복잡성을 낮출 수

 

레이어 중간에 공유 중개자를 두어

로드밸런싱 및 캐시 정책을 도입할 수 있게

 

계층별로 독립적인 기능을 수행하기 때문에,

특정 기능이 오래되어 (레거시 서비스) 교체가 필요할 때에도

새로운 서비스를 완전히 격리할 수

 

그러나 계층적으로 일이 처리되다 보면

데이터 처리에 과부하가 더해지므로 응답이 늦어질 수 

6. Code on demand 

server가 네트워크를 통해 client에 전달한

javascript 등과 같은 프로그램들은

그 자체로 실행이 될 수 있어야 

 

 즉, server로부터 기능을 내려받아 client에서 바로 실행할 수 있어야 한다

--> 사전에 구현에 필요한 기능의 수를 줄임으로써 client를 단순화할 수 

 

정적인 데이터를 xml 또는 json에 담아서 client로 보내고

client가 이 데이터를 가공하는 방식이 있으나

 

code on demand 원칙은

client에 보내는 데이터를

바로 실행 가능한 코드의 형태도 보내어 client가 곧바로 실행하는 것

 

시스템 확장성이 향상되지만,

 

오히려 client 입장에서는 실행할 코드를

백엔드에서 받기 전에는 전혀 알 수가 없기 때문에 가시성이 낮아짐

 

따라서 선택적인 원칙

조직 내부에서는 사용 가능하지만, 외부에서는 사용이 불가능할 수 

[GET] http://10.58.4.1:3000/detail_page (x)   --> /products/1

[GET] http://10.58.4.1:3000/main_page (x)   --> /products

 

틀린 이유:

* page라는 건 없음. 

    - main page 전체 페이지 = products 

    - detail page 상세 페이지 = 어떤 상품의 상세페이지인지, 정확하게

 

* URI →어떤 정보를 줄 지 정확하게 명시 

 

ex. 에어비엔비는 상품 없으니, product 대신 accomodation 

---

[POST] http://10.58.4.1:3000/add/posts (x) --> /posts

 

틀린 이유:

Add 동사는 필요 없음 → 입력하는거 원하면 post

---

[POST] http://10.58.4.1:3000/product-review  (x)  --> products/3/reviews

 

상품 리뷰 작성 만들어서 프론트에게 준 거 

 

틀린 이유:

 어떤 상품의 리뷰인지 → 계층을 정확하게, 어느 Product의 리뷰인지 

3번 상품에 리뷰를 posting 을 하는

 

길어지면 / 를 쓴다

---

[GET] http://10.58.4.1:3000/products-filter (x) --> products?color= 

 

틀린 이유:

어떤 필터를 하는지, 필터의 기준 

---

[Parameter]

상품 백만개를 다 따라  product1,2,3, ... 만들 수 없으니, 

Parameter 사용 

 

두 가지 종류 

1. path parameter

2. query parameter 

 

1.  path parameter 

Project 2- 2일 차: [API]세션(1) Path parameter

1) 특정 uri를 구체적으로 지칭할 때 (get)

2) 데이터 저장(post)

 

3) , 특정 데이터 수정 (patch)

ex. 가격 수정하기 

4) 특정 데이터 삭제 (delete)

 

1번 상품을 삭제할 거야 (프론트 -백엔드) 

1번 상품 없어 (백엔드 -프론트) 

 

---

2. Query parmeter

Project 2- 2일 차: [API]세션(2) Query Parameter

2-1. path vs. query 

Path parameter 는 숫자만 있었는데 (product/1) 

Query parmeter 는 price도 

 

2-2. Query 쓸 때: 

2-2-1. Filtering

최신순/신상품, 사이즈 별, 가격별, 페이지 수, 매출량 순 

 

순서만 바꿀 때

고객이 어떤 순으로 원하는지 모르니까

 

- api 형태는 안 바뀜

 

2-2-2. Ordering

조건만 다를 때,

같은 api,

router도 분리 안하고 똑같이 사용

 

백엔드가

sql로 정렬 후 바꿔서, 프론트에게 보내줌

 

프론트가

정보 받은 후에 정렬 바꾸는 게 아니라. 

 

• 가격순 (높은 순/ 낮은 순) 
• 할인순 
• 추천순
• 최신순 
• 매출량 순 

 

마이너스는 (반대로한다라는 뜻) 

---

2-2-3. Pagination 

프론트가 자바스크립으로 수정하는거보다 백엔드가 sql로 수정하는게 빨라서 

속도 면에서 

고객의 편의를 위해 백엔드가 해서 보내 주는 것 

 

카페 찾아줘 → 저 부분이 위치 같음

그래서 로딩 이 필요한 게 백엔드가 가져와야 하니 

---

2-2-4. Searching  

일반 get/users와 같지만

search= 홍길동 

 

깃허브 위코드 repository에 엄청 많은데,

 

자바스크립트만 골라내고 싶으면, 

주소에 language=javascript 치면 됨 

--> 직접 버튼으로

language- javascript 하는거랑 같은 방식

 

파이썬만 골라내고 싶으면

주소창에 language= python

 

그렇다도 데이터의 형태가 바뀌는 게 아님, 필터링만 될 뿐

2-4. when to use? 

path = 특정한 값 뽑을 때 

query = 옵션을 줄 때 (filter/order정렬/pagination/searching 검색)

 

프론트 입장 

Path parameter → 상세페이지 고를 때 씀 (하나의 상품만 보일 때, 혹은 팝업으로 하나의 상품 보여줄 때) "3번 product 보여줘"

Query parameter → 전체 목록페이지 메인페이지에서, id=3 인 것만 골라낼 때       "product id=3 보여줘"

 

백엔드 입장

프론트와  비슷하지만 프론트처럼 페이지 단위로 생각하면 안됨

데이터 중심으로 생각해야함.  = '구체적 정보를 요구하는구나 '생각 

 

Path parameter → 상세 정보는 상세페이지에서만 쓰이지 않을 수도 있음

프론트가 '잘 팔리는 상품 3개'로 -->  이렇게 메인/상세페이지에서 하나씩 보여줄 수도 있기에. 

 

Query parameter (프론트와 같음)→  전체 목록페이지 메인페이지에서, id=3 인 것만 골라낼 때      "product id=3 보여줘"

 

두개의 함수가 다르기에, router 분리 해야 함. 

Query 안에서 조건문으로 분기처리 해야 함

---

cf. 

카테고리 상품 = 1 만드는 사람 티켓

카테고리 상품 = 2 만드는 사람 티켓

이런식으로 분리하면 안 되고 

합쳐서 생각해야 함

 

 

 

hot jar: 사용자의 움직임(마우스 움직임) 을 녹화함 (저스트코드에서 노란색 해놓은데,

(1달, 2달 통계치 / 많은 사용자의 데이터니 의미있는 지표일 수, 잘 걸러서 봐야 )

- 사용자가 많이 보는게,  여기인데 여기에서 로딩 느리면 수정하고

- 배포 후, 다시 기획 하고 그럼. (개발자에게 배포는 축복) 

 

핑거프린트도 수집 됨 (클릭 어디 됐는지 다 보임)

나의 의견: 
--> 그런데 요즈음은 펜/손으로 그으면서 눈으로 모바일로 많이 봐서  보면서 무의식 중에어디 보고 있는지, 데이터 수집이 안 될 듯 하다)