REST를 사용해야하는 이유는 무엇입니까?
게시물로만 작업을 완료하고 요청을받을 수 있는데 왜 REST를 사용해야합니까?
Roy Fielding 은 REST로 가장 한 RPC 에 대해 약간의 불만 을 표명했습니다 .
REST는 클라이언트와 서버가 매우 느슨하게 결합되어 있기 때문에 매우 잘 확장되는 하이퍼 텍스트의 사용을 요구합니다. REST를 사용하면 서버는 자유롭게 노출 된 리소스를 자유롭게 변경할 수 있습니다. REST 자체가 정의하는 것 이상의 고정 API는 없습니다. 클라이언트는 초기 URI 만 알고 있으면 서버에서 제공하는 선택 항목 중에서 선택하여 탐색하거나 작업을 수행합니다. 서버는 탐색 및 상태 표현에 도움이되는 코드를 클라이언트에 다운로드 할 수 있습니다.
이 모든 것은 클라이언트와 서버가 일반적으로 양쪽 끝으로 컴파일되어야하는 세부 프로토콜 (예 : 특정 순서로 액세스되는 특정 형식의 URI)에 동의해야하는 다양한 RPC (원격 프로 시저 호출) 체계와 완전히 대조됩니다. 한쪽 끝에서는 SOAP / WSDL / WS *). 이 접근 방식은 서버와 클라이언트 모두에서 동시에 변경 사항을 구현해야하기 때문에 취약합니다. 서버 및 / 또는 클라이언트 수가 증가함에 따라 빠르게 사용할 수 없게됩니다. 특히 서버는 인기가 높아질수록 게시 된 API의 진화가 점점 더 어려워지기 때문에 어려움을 겪습니다.
이러한 요소를 고려할 때 가능하면 REST가 항상 더 나은 선택입니다. 이는 서버의 신속한 진화를 가능하게하고 천문학적 수의 애플리케이션이 임시 기반 (예 : 전체 인터넷)에서 자유롭게 상호 작용할 수 있도록합니다.
그러나 "가능한 경우"부분은 어떻습니까? REST는 루프에 사람이있을 때 가장 잘 작동합니다. 결국, 인간은 이전에 알려지지 않은 옵션 세트를 제시 할 때 합리적인 선택을 할 수있는 좋은 기회가 있습니다. 기계는 아직 없습니다. 웹 RPC 프로토콜은 양쪽을 고정 된 프로토콜로 정확하게 수갑시키기 위해 탄생했습니다. 이렇게하면 사람이 그림에서 제거 될 때 자동화 된 프로세스가보다 쉽게 통신 할 수 있습니다. RPC는 순전히 자동화 된 작업이 진화 및 확장 성 (인터넷 시간 및 인터넷 규모)보다 더 중요한 경우 유효한 설계 선택입니다.
규모와 결합?
여기서 "규모"는 넓은 의미로 의미합니다. 여기에는 사용자 수와 세션 수가 포함됩니다. 물론 응용 프로그램 크기와 개발 프로세스도 포함됩니다. 긴밀한 결합은 애플리케이션 크기에 심각한 장애를 제공합니다. REST 아키텍처가 제공하는 매우 느슨한 결합이없는 가장 큰 알려진 애플리케이션 인 World-Wide Web의 존재를 상상하기 어렵습니다. 전 세계 수백만 개발자가 수십억 명의 사용자를 지원하는이 애플리케이션을 구축하기 위해 협력했습니다. 그러나 개발자는 서로를 행복하게 인식하지 못하면서이를 수행합니다 (또는 StackOverflow가 아니었다면 적어도 서로를 인식하지 못할 것입니다).
REST의 기본 활성화 원칙은 하이퍼 텍스트입니다. 아키텍처의 다른 요소는 매우 큰 규모 (모든 의미에서)이 원칙을 지원하기 위해 존재합니다. REST가 웹을 구축 할 수있는 유일한 방법일까요? 아니요.하지만 이는 사실상 성공적인 표준입니다. 생태계에 새로운 진입을위한 기본 선택이어야하며 신중하고 명시적인 설계 고려 후에 만 폐기됩니다.
REST를 올바르게 사용하면 시스템 구성 요소가 적절하게 분리 된 상태로 유지되고 일반적인 RPC와 유사한 방식으로 직접 연결 한 경우보다 미래에 더 쉽게 발전 할 수 있습니다. 응용 프로그램의 요구 사항에 따라 선택해야하는 아키텍처 선택입니다. 다른 사람들은 기술적 인 이점 중 일부를 언급했으며 이것도 고려해야합니다.
REST를 사용하면 API 디자인을 쉽게 발전시킬 수 있습니다. 이것이 REST의 핵심입니다. API를 만들고 있습니다. 의견 중 일부는이 생각의 측면을 다루었지만 실제로 핵심 문제를 실현하지는 못했습니다. REST를 다룰 때 클라이언트 (또는 자신)가 사용할 API를 생성합니다. 리소스에 대한 HTTP 작업은 클라이언트에게 API 설계 및 기능에 대한 명확한 표시를 제공합니다. 따라서 올바른 HTTP 동사를 올바르게 사용하면 표준화되고 클라이언트 관점에서 이해할 수있는 API를 선언하는 것입니다.
GET요청이 멱 등성이 아닌 경우 서버와 클라이언트 간의 HTTP 캐싱으로 인해 애플리케이션 이 중단 됩니다. POST요청은 정의상 멱 등성이 아니므로 HTTP 캐시는 이러한 요청과 결과를 캐시하지 않습니다 GET. 애플리케이션의 프로토콜을 위반하지 않고도 요청 을 캐시하는 이점을 얻을 수 있습니다. 훌륭한 성공.
그리고 객체를 삭제해야하는 경우 삭제를 요청하는 DELETE것보다 와이어 및 로그에서 읽기가 훨씬 쉽습니다 POST. 그러나 웹 브라우저는 DELETE동사를 사용하여 HTTP 요청을 쉽게 할 수 없으므로 직접 프로그래밍 한 클라이언트에 더 적합합니다.
REST에서는 검색이 훨씬 쉽습니다. 귀하의 서비스를 전 세계에 알리는 데 도움이되는 WADL 문서 (기존 웹 서비스의 WSDL과 유사)가 있습니다. UDDI 발견도 사용할 수 있습니다. 전통적인 HTTP POST 및 GET을 사용하면 사람들이 메시지 요청 및 응답 스키마를 모를 수 있습니다.
REST는 리소스 / 객체에 대해 수행하려는 모든 잠재적 작업을 실제로 포함하므로 사용해야합니다.
- GET-주어진 조건에 따라 리소스 검색
- POST-리소스 생성
- PUT-주어진 업데이트 된 속성으로 자원 업데이트
- DELETE-리소스 삭제
또 다른 이유는 모든 사람이 구현하고 사용할 수있는 표준이기 때문입니다. 표준화가 중요한 이유에 위로 읽으려면, 내가 읽고 제안 이 와 이 (오히려 재미이지만, 정말 사람들이 REST의 개념을 파악하는 데 도움).
다음과 같은 기능과 장점 때문에 REST를 사용해야합니다.
풍모
- Stateless 클라이언트 / 서버 프로토콜 : 각 HTTP에는 실행에 필요한 모든 정보가 포함되어 있습니다. 즉, 클라이언트와 서버 모두이를 충족하기 위해 이전 상태를 기억할 필요가 없습니다. 일부 HTTP 응용 프로그램은 캐시 메모리를 통합합니다. 이것은 상태 비 저장 클라이언트-캐시-서버 프로토콜로 알려진 것을 구성합니다. 특정 HTTP 요청에 대한 일부 응답을 캐시 가능으로 정의 할 수 있으므로 클라이언트가 나중에 동일한 요청에 대해 동일한 응답을 실행할 수 있습니다. 그러나 옵션이 존재한다고해서 이것이 가장 권장되는 것은 아닙니다.
- REST 시스템 및 HTTP 사양에는 POST (생성), GET (읽기 및 참조), PUT (편집) 및 DELETE의 네 가지 매우 중요한 데이터 트랜잭션이 있습니다.
- REST의 객체는 항상 URI에서 조작됩니다 . 이 REST 시스템에서 각 리소스의 유일한 식별자는 URI이며 다른 요소는 없습니다. URI를 사용하면 정보를 변경 또는 삭제하거나 제 3 자와 정확한 위치를 공유하기 위해 정보에 액세스 할 수 있습니다.
- 균일 한 인터페이스 : 데이터를 전송하기 위해 REST 시스템은 리소스에 특정 작업 (POST, GET, PUT 및 DELETE)을 적용합니다 (단, URI로 식별되는 경우). 이를 통해 정보로 프로세스를 체계화하는 균일 한 인터페이스를 쉽게 얻을 수 있습니다.
- 계층 시스템 : 구성 요소 간의 계층 구조. 각 계층에는 REST 시스템 내에 기능이 있습니다.
- 하이퍼 미디어 사용 : 하이퍼 미디어는 1965 년 Ted Nelson이 만든 용어로 하이퍼 텍스트 개념의 확장입니다. 웹 페이지 개발에 적용되는이 개념은 사용자가 HTML 링크를 통해 개체 집합을 탐색 할 수 있도록합니다. REST API의 경우 하이퍼 미디어 개념은 클라이언트와 사용자에게 데이터에 대한 특정 작업을 실행하기위한 적절한 링크를 제공하는 앱 개발 인터페이스의 용량을 설명합니다.
장점
- 클라이언트와 서버 간의 분리 : REST 프로토콜은 사용자 인터페이스를 서버 및 데이터 저장소에서 완전히 분리합니다. 이것은 개발할 때 몇 가지 장점이 있습니다. 예를 들어, 다른 유형의 플랫폼에 대한 인터페이스의 이식성을 향상시키고 프로젝트의 확장 성을 높이며 개발의 다양한 구성 요소를 독립적으로 발전시킬 수 있습니다.
- 가시성, 신뢰성 및 확장 성 . 클라이언트와 서버를 분리하면 한 가지 분명한 이점이 있으며 이는 각 개발 팀이 너무 많은 문제없이 제품을 확장 할 수 있다는 것입니다. 각 요청의 데이터가 올바르게 전송되면 다른 서버로 마이그레이션하거나 데이터베이스에서 모든 종류의 변경을 수행 할 수 있습니다. 분리를 통해 앞면과 뒷면을 서로 다른 서버에 배치하기가 더 쉬워지고 앱이 더 유연하게 작업 할 수 있습니다.
- The REST API is always independent of the type of platform or languages: the REST API always adapts to the type of syntax or platforms being used, which gives considerable freedom when changing or testing new environments within the development. With a REST API you can have PHP, Java, Python or Node.js servers. The only thing is that it is indispensable that the responses to the requests should always take place in the language used for the information exchange, normally XML or JSON.
Why do you think only using POST and GET means it's not REST?
The point to REST is that each "resource" has a resource identifier, a URI. Each URI potentially has GET, POST, PUT, DELETE.
- GET is read
- POST is update
- PUT is create
- DELETE is delete
If you're not doing some of those things -- like PUT is kind of rare and a potential security hole -- then you don't.
ReferenceURL : https://stackoverflow.com/questions/5320003/why-we-should-use-rest
'Programing' 카테고리의 다른 글
| 매개 변수 사용에 JSP 포함 (0) | 2020.12.31 |
|---|---|
| jQuery serializeArray가 클릭 한 제출 버튼을 포함하지 않습니다. (0) | 2020.12.31 |
| TypeError : 유니 코드로 강제 변환 : 문자열 또는 버퍼 필요 (0) | 2020.12.31 |
| Java Set에서 * 모든 * 값을 얻는 좋은 방법은 무엇입니까? (0) | 2020.12.31 |
| 사용자 정의 열거 형도 직렬화 가능합니까? (0) | 2020.12.30 |