본문 바로가기

카테고리 없음

what is REST?

 

아래 3개의 글을 읽으면 rest에 대해 잘 이해할 수 있을 것이다. 특히 마지막 것을 잘 봐라. 

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

 

[Network] REST란? REST API란? RESTful이란? - Heee's Development Blog

Step by step goes a long way.

gmlwjd9405.github.io

 

https://sanghaklee.tistory.com/57

 

RESTful API 설계 가이드

1. RESTful API 설계 가이드 본 문서는 REST API를 좀 더 RESTful 하게 설계하도록 가이드할 목적으로 만들어졌다. 따라서, 기본적인 REST API 개념 설명은 아래의 링크로 대신한다. REST API 제대로 알고 사용

sanghaklee.tistory.com

 

아래 글 좋다.!

https://wonit.tistory.com/454

 

HATEOAS를 모르면 당신이 알고 있는 REST API는 REST API가 아니라고 장담할게요.

이 글은 그런 REST API 로 괜찮은가? 의 이응준 개발자님의 발표 자료에 여러 부분을 차용하였습니다. REST API란 무엇일까 난 지금까지 REST API에 대해서 상당 부분을 오해하고 있었다. REST API라고 함

wonit.tistory.com

먼저 REST와 REST API를 분리해서 설명하고 있다. 이 둘은 다른 개념인듯?
REST가 뭔지 설명하라고 하면 아래의 사진이 젤 맞는 것 같다.

@

모든 자원에 URI를 할당해야한다. 예를 들어 사진을 서버에 저장할 때 사진은 보통 DB에 저장히지 않고 파일로 저장하고 DB에는 파일 경로만 저장한다. DB에 사진 자체를 저장하면 병목현상 생기고 굳이 DB에 저장할 이유가 없다. REST를 지키려면 사진 각각에 대해서도 CRUD를 HTTP method로 표현해야함...

예를 들어 이번에 하는 프로젝트에서는 클라이언트에서 주문(텍스트)과 함께 사진을 보낸다. 내가 짠 API는 주문테이블에 대한 PK를 클라이언트가 보내면 POST로 넘어온 사진도 함께 저장, 업데이트하거나 사진을 반환해주는 식으로 구성했다. 하지만 REST하게 서버를 짠다면 각각의 주문에 대해서 URI를 설정, 각각의 사진에 대해서도 URI를 설정해서 클라이언틀가 사진, 주문에 대해 CRUD할 수 있어야 했다. 약간 타협해서 주문, 사진 따로 CRUD를 구성하지는 아니더라도 주문에 대해 메소드 방식에 따라 동작을 다르게 해서 API를 구성해야 했다.

 


윗 블로그를 읽고 질문을 정리했다.

 

Q : 아래에 나와있는 것은 REST의 특징이다. context를 server에 저장하지 않는다고 했다. 세션 쿠키와 같은 context정보를 신경쓰지 않아도 된다면 어떻게 로그인 기능을 구현한다는 말인가?

REST의 특징

-> 아마 JWT?

 

 

 

Q : 그리고 분산시스템을 위한 것이라고 했는데 도대체 이렇게 해서 얻는 장점이 무엇인가? 어떤 구체적인 상황에서 분산시스템에 장점이라는 것인가?