자바 스프링을 공부하기에 카테고리는 마땅히 추가할 곳이 없어 스프링에 분류했습니다.
F-lab 2주차 RESTful 에 대하여 한번 공부해보라는 과제가 주어져 한번 찾아보게 되었다. 자바 스프링 공부를 하면 자연스럽게 HTTP 도 공부를 하게 되는데 그 과정에서 REST라는 단어를 많은 사람들이 쓰는것을 보았고 RESTful 하다. RESTful 하지않다. REST API 를 만드려면 어떻게 해야하나요? 라는 글 같은 것을 많이 봤지만 아직 나랑은 먼 단계 라고 생각하여 자세하게 알아 볼 생각은 없었다.. 반성하자
과제도 과제이지만 이미 많은 사람들이 언급하는 것으로 보아 중요할 것 같은데 왜 이런 말들이 많을까 한번 알아보고 정리해봤다.
왜? 라는 이유에 집중을 해봤다.
REST
REST(REpresentational State Transfer)?
Representational State => 상태를 표현한다.
- URL 로 리소스를 표현(=식별)하고 조작은 메서드를 통해 조작한다.
- State: URI안의 상태(State) 를 포함해라
- URL 자체는 정보의 완정성을 띄어야 한다. => HTTP 메서드를 바꿔도 하나의 컨텐츠를 조작할 수 있어야 한다.
- 웹에서 컴퓨터 시스템 간에 표준을 제공하여 시스템이 서로 더 쉽게 통신할 수 있도록 하는 아키텍처 스타일
*아키텍쳐 스타일 ⇒ 제약조건의 집합
탄생하게 된 이유?
How do I improve HTTP without breaking in the web
- roy Fielding -
- 웹을 깨뜨리지 않고 HTTP를 개선할 수 있을까? 라는 고민에서 시작
REST API 란?
- REST 아키텍쳐 스타일을 따르는 API
- 하이퍼텍스트를 포함한 self-descriptive한 메시지의 uniform interface를 통해 리소스에 접근하는 API
제약 조건(아키텍쳐 스타일)
1. client - server
- 클라이언트-서버의 각 파트가 독립적으로 개선될 수 있도록 해준다.
2. stateless
- 클라이언트의 context가 서버에 저장되어서 안됨
- 요청만 처리하면 되기 때문에 서버에서 불필요한 정보를 관리 하지 않아 구현이 단순하여 확장성이 좋다
- 분리를 통해 구성 요소를 독립적으로 발전시켜 여러 조직 도메인의 인터넷 규모 요구 사항을 지원할 수 있다
3. cache
- 캐시는 클라이언트가 동일한 리소스에 대해 반복해서 서버를 요청할 필요가 없도록 하는 것
- 캐시 제약 조건은 요청에 대한 응답 내의 데이터에 암시적 또는 명시적으로 캐시 가능 또는 캐시 불가능으로 레이블이 지정되어야 함
4. uniform interface
- REST 아키텍처 코드스타일을 다른 네트워크 기반 스타일과 구별하는 핵심 기능은 구성 요소 간의 균일한 인터페이스를 강조
5. layered system
- 인터넷 규모 요구 사항에 대한 동작을 더욱 개선하기 위해 계층화된 시스템 제약 조건을 추가
6. code-on-demand (optional)
- 서버에서 코드를 클라이언트로 보내서 실행시킬 수 있어야 한다. (자바스크립트)
*Uniform Interface의 제약 조건
1. identification of resources
- 리소스가 URI 로 식별되면 된다.
- 각 URL이 단일 리소스에 매핑되어야 하며 이 리소스에 대한 모든 액세스는 해당 URL을 통해 수행
2. manipulation of resources through representations
- representations을 통한 리소스를 조작
- 서버가 리소스 표현을 전송하므로 클라이언트가 클라이언트의 요구에 맞는 특정 표현을 요청할 수 있다
3. self-descriptive messages
- 메시지는 스스로 설명해야한다. → 요청, 응답 메시지의 내용으로 온전히 해석이 다 가능해야한다.
- 서버나 클라이언트가 변경이 되더라도 오고가는 메시지는 언제나 self-descriptive 하므로 해석이 가능하다.
4. hypermedia as the engine of application state(HATEOAS)
- 애플리케이션 상태는 Hyperlink를 이용해 다음 상태로 전이되어야 한다.
- 이것은 HTML처럼 하이퍼링크가 추가되어서 다음에 어떤 API를 호출해야 하는지를 해당 링크를 통해서 받을 수 있어야 합니다.
하지만 대부분 RESTful API는 self-descriptive messages 와 hypermedia as the engine of applicationstate(HATEOAS) 두 개가 잘 지켜지지 않는다. 사실상 대부분이 HTTP API 그렇지만 실무, 많은 사람들이 저 두가지를 제외해도 REST API 라고 부른다.
왜 제약조건을 지켜야 하는가?
독립적 진화 를 하기 위해, REST는 웹의 독립적의 진화를 위해 만들어졌다.
- 서버와 클라이언트는 각각 독립적 진화한다.
- 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없다.
어떻게 확인하는가?
- 웹 페이지를 변경한다고 웹 브라우저를 업데이트할 필요가 없다.
- 웹 브라우저를 업데이트했다고 웹 페이즈를 변경할 필요가 없다.
- HTTP 명세가 변경되어도 웹은 잘 동작한다.
- HTML 명세가 변경되어도 웹은 잘 동작한다.
API는 왜 REST 하기 어려울까?
- HATEOAS 와 Self-descriptive 를 지키기위한 단점과 번거로움이 있다. (참조된 유튜브 40:30)
REST 왜 사용할까?
- 결국 REST의 모든 이유는 웹을 표준화하는 것
- 각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능해짐
API?
API는 애플리케이션 소프트웨어를 빌드하고 통합하기 위한 정의 및 프로토콜 세트인 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 뜻합니다.
- 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령을 받을 수 있는 수단
- API는 사용자가 원하는 것을 시스템에 전달할 수 있게 지원하여 시스템이 이 요청을 이해하고 이행하도록 할 수 있다.
- API를 사용자 또는 클라이언트, 그리고 사용자와 클라이언트가 얻으려 하는 리소스 사이의 조정자로 생각
Best practices REST API ?
*가장 중요한 사항은 웹 표준 및 규칙을 준수하여 일관성을 유지해야 한다.
1. JSON으로 수락 및 응답
- JSON은 데이터 전송의 표준입니다. 거의 모든 네트워크 기술에서 사용할 수 있습니다.
2. 마지막 경로에서 동사 대신 명사 사용
- HTTP 요청 메서드에 이미 동사가 있기 때문
- GET은 리소스를 검색
- POST는 새 데이터를 서버에 제출
- PUT은 기존 데이터를 업데이트
- DELETE는 데이터를 제거
3. 마지막 경로에 논리적 중첩 사용
4. 오류를 적절하게 처리하고 표준 오류 코드를 반환
- API의 유지 관리자들에게 발생한 문제를 이해하기에 충분한 정보를 제공한다.
5. 필터링, 정렬 및 페이지 지정 허용
- 데이터베이스가 매우 커질 수 있어 속도저하, 시스템 다운 방지를 위해 한 번에 모두 반환X →항목을 필터링
- 한 번에 몇가지 결과만 반환하도록 데이터를 페이징
- 필터링 및 페이지 분할은 모두 서버 리소스 사용을 줄임으로써 성능을 향상. 데이터베이스에 더 많은 데이터가 축적될수록 이러한 기능들은 더욱 중요해짐
6. 우수한 보안 유지
- 개인 정보를 자주 주고 받기 때문에 이런 통신은 비공개여야 한다.
- SSL / TLS 사용
7. 성능 향상을 위한 캐시 데이터
- 사용자가 데이터를 더 빨리 얻을 수 있다
8. API 버전 관리
- 모든 사람이 동시에 새 API로 이동하도록 하는 대신 이전 엔드포인트를 점진적으로 단계적으로 제거가능
- v1 엔드포인트는 변경을 원하지 않는 사람들을 위해 활성 상태를 유지할 수 있는 반면, 새로운 기능을 갖춘 v2는 업그레이드할 준비가 된 사람들에게 서비스를 제공 가능
[reference]
https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/
https://www.youtube.com/watch?v=RP_f5dMoHFc&ab_channel=naverd2
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
https://en.wikipedia.org/wiki/Representational_state_transfer
https://sookocheff.com/post/api/how-rest-constraints-affect-api-design/
참고로 https://www.youtube.com/watch?v=RP_f5dMoHFc&ab_channel=naverd2 이 유튜브는 꼭 한번 시청하기를 권해봅니다.
'스프링' 카테고리의 다른 글
| 서블릿(Servlet) (0) | 2022.05.31 |
|---|---|
| 싱글톤 패턴(Singleton) (0) | 2022.05.26 |
| 관심사의 분리(Seperation Of Concern) (2) | 2022.05.18 |
| 스프링(Spring)은 왜 사용할까? (0) | 2022.03.25 |
| @Bean 과 @Component 의 차이? (0) | 2022.03.22 |