REST와 URI 설계 패턴

kkjj·2022년 5월 7일
0

REST(Representational State Transfer:자원의 상태전달) - 네트워크 아키텍처

1.Clint,Server: 클라이언트와 서버가 서로 독립적으로 분리 되어있어야 한다.

2. Stateless:요청에 대해서 클라이언트의 상태를 서버에 저장하지않는다.

3. Cache:클라이언트는 서버의 응답을 Cache(임시저장) 할수있어야한다, 클라이언트가 Cache를 통해서 응답을 재사용할수 있어야 하며, 이를통해서 서버의 부하를 낮춘다.

4. 계층화(Layered System): 서버와 클라이언트 사이에,방화벽,게이트웨이,Proxy 등 다양한 계층 형태로 구성이 가능해야 하며, 이를 확장 할 수 있어야한다.

5. 인터페이스 일관성: 인터페이스의 일관성을 지키고,아키텍처를 단순화 시켜 작은단위로 분리하여,클라이언트,서버가 독립적으로 개선 될수 있어야한다.

6. Code on Demand(Optional):자바 애플릿, 자바스크립트, 플래시 등 특정한 기능을 서버로 부터 클라이언트가 전달받아 코드를 실행할수 있어야 한다 .

다음의 인터페이스 일관성이 잘지켰는지에 따라,REST를 잘 사용했는지 판단을 할 수 있다.

1.자원의 식별

2. 메시지를 통한 리소스 조작

3. 자기 서술적 메시지

4. 애플리케이션 상태에 대한 엔진으로써 하이퍼미디어

자원의 식별

웹기반의 REST에서는 리소스 접근을 할때 URI를 사용합니다.

https://foo.co.kr/user/100

Resource: user

식별자:100

메시지를 통한 리소스 조작

Web에서는 다양한 방식으로 데이터를 전달 할수있습니다.

그중에서는 가장많이 사용하는 방식은 HTML,XML,JSON,TEXT등이 있다

이중에서 어떠한 타입의 데이터인지를 알려주기 위해서 HTTP Header 부분에 content-type 을 통해서 데이터의 타입을 지정해 줄수 있습니다.

또한 리소스 조작을 위해서 데이터 전체를 전달 하지 않고, 이를 메시지로 전달합니다.

EX) 서버의 user라는(db)의 전화번호를 처음에는 number 라는 결정했고, 이정보를 Client와 주고 받을때, 그대로 사용하고 있었다면, 후에 서버의 resource변경으로 phon-number로 바뀌게 된다면 Client는 처리를 하지 못하고 에러가 난다. -->데이터 전체를 전달하기때문에 이러한문제가 발생한것 독립적으로 확장이 불가한다.

이러한 부분을 방지하기 위하여,별도의 메시지의 형태로 데이터를 주고받으며, client-server가 독립적으로 확장 가능하도록 한다.

자기서술적 메시지

요청하는 데이터가 어떻게 처리 되어져야하는지 충분한 데이터를 포함 할수있어야 한다.

HTTP 기반의 REST에서는 HTTP Method와 Header 정보,그리고 URI의 포함되는 정보로 표현 할수 있습니다.

GET: https://foo.co.kr/user/100 , 사용자의 정보 요청

POST: https://foo.co.kr/user , 사용자 정보 생성

PUT: https://foo.co.kr/user , 사용자 정보 생성및 수정

DELETE : https://foo.co.kr/user/100,사용자 정보 삭제

그외에 담지 못한 정보들은 URI의 메시지를 통하여,표현한다

Application 상태에 대한 엔진으로써 하이퍼 미디어

이러한 조건들을 잘 갖춘 경우, REST Ful 하다고 표현하고, 이를 REST API 라고 부른다.

URI 설계 패턴

1. URI(Uniform Resource Identifier)

인터넷에서 특정자원을 나타내는 주소값.해당 값은 유일하다(응답은 달라질수 있다)

요청: https://www.fqweqwe.co.kr/resource/sample/1

응답: fqweqwe.pdf,fqweqwe.docx

2.URL(Uniform Resource Locator)

인터넷 상에서의 자원,특정 파일이 어디에 위치 하는지 식별하는 주소 , 지정된 딱 위치이기에 변경될수가없다.

요청:https://www.asdasq.co.kr/asdasd.pdf

URL은 URI 의 하위 개념 이다.

1.URI 설계원칙(RFC-3986)

  • 밑줄(_)은 사용하지 않는다.

--> 이것이 왜 위협이 되냐면 ,jsp특정 버전에 보안취약점이 생기다던지 특정언어에 문제가 생기다던지 특정 웹구성하는 프레임워크에 문제가 생기다면 굳이 외부에 노출할때 이러 부분을 노출할 필요x

  • 명사에 단수형 보다는 복수형을 사용해야한다. 컬렉션에 대한 표현은 복수로 사용
    https://asdas.co.kr/classes/java/curriculums/web
  • 경로 부분 중 변하는 부분은 유일한 값으로 대체한다
    생략.../curriculums/web/lessons/{lesson-id}/users/{user-id}
    생략.../curriculums/web/lessons/2/users100
  • CRUD 기능을 나타내는것은 URI에 사용하지않는다.
    GET:생략.../curriculums/web/lessons/2/users/100/READ (X)
    DELETE:생략.../curriculums/web/lessons/2/users/100 (O) --> DELETE 메소드를 사용하는게 원칙임
  • URI Query Parameter 디자인
    URI 쿼리 부분으로 컬렉션 결과에 대해서 필터링 할수있다.
    생략.../curriculums/web-study?chapter=2
  • URI 쿼리는 컬렉션 결과를 페이지로 구분하여 나타내는데 사용한다
    생략.../curriculums/web-slss?chapter=2&page=0&size=10&sort=asc
  • API에 있어서 서브 도메인은 일관성 있게 사용해야한다.
    https://naver.com
    https:// api.naver.com
    https://api-naver.com
    --> 이것의 용도는 실제 운영 환경 사용자들이 쓰는 환경을 개발하기전에 개발환경에서 개발하고 테스트해야하는데 그때 사용하는데 하이픈 이나 앞에 쓴다.
  • 클라이언트 개발자 포탈 서브 도메인은 일관성 있게 만든다.
    https://dev-naver.com
    https://devloper-naver.com
profile
백엔드

0개의 댓글