REST - 왜 우리는 백만 개의 URL과 다른 HTTP 요청이 필요합니까?

Question

가능한 중복은 :

REST API - why use PUT DELETE POST GET?

나는이 question 물었다. 하지만 좋은 API를 만들기 위해 DELETE/PUT/POST/GET을 사용하는 이유는 아직 모르겠다.

요청 매개 변수의 모든 정보를 전달하는 것이 훨씬 쉽지는 않겠지 만 당신의 API를? 다음

GET www.example.com/api?id=1&method=delete&returnformat=JSON 
GET www.example.com/api?id=1&method=delete&returnformat=XML 

또는

POST www.example.com/api {post data: id=1&method=delete&returnformat=JSON} 
POST www.example.com/api {post data: id=1&method=delete&returnformat=XML} 

과에 대한 단일 항목-POINT - 우리가 URL을 수백 필요없이 내부적으로 모든 방법과 데이터를 처리 할 수있는 ...

어떻게 이런 유형의 API를 호출할까요? REST가 아닌 SOAP입니다. 그 다음은 무엇입니까?

업데이트 여기에 새로운 표준을 제안하는 것이 아닙니다. 웹 서비스가 왜 그들이 작동하는 방식으로 작동하는지 더 잘 이해하기 위해 질문하는 것뿐입니다.

업데이트 2 흠. Ok - 얼마 동안 인터넷 검색을하고 다양한 API를 살펴본 후이 접근 방식이 JSON-RPC의 접근 방식에 가장 가깝습니다. 그것은 재미있어 보인다. 예를 들어 야후 메일에 구현되어 있습니다. yahoo mail json-rpc api

Answer 1

HTTP 동사를 사용하면 RESTful이됩니다. 쿼리 문자열 매개 변수를 사용하여 리소스에서 수행 할 작업을 지정하면 더 이상 REST가 아닙니다.

REST는 HTTP 동사를 사용하므로 HTTP 동사가 표준화되어 있기 때문에 API마다 다를 수있는 메서드 이름을 파악할 필요가 없습니다. 물론 새로운 ANDREful 접근 방식을 만들 수 있으며 메서드 매개 변수를 항상 메서드라고 부르며 특정 값으로 만 구성 할 수 있어야합니다.

쉬워 질까요? 너무 주관적입니다. 무엇이라고 이름 붙이시겠습니까? 네가 원한다면.

Answer 2

내가 제안한대로 API를 설계 한 응용 프로그램을 사용해야했습니다. 이전 스타일 API에 대한 경험으로 인해 이제 REST API를 작성합니다. 당신이 제안하고있는 것은 약 10 년 전 꽤 흔한 관행이었습니다. 웹은 그 이후로 배웠으며 지금은 더 잘 알고 있습니다.

결국 API를 작성하는 방법이 쉽지 않습니다. 더 힘들어. 모두를위한. 긴 쿼리 문자열을 조작하고 GET 요청 만 사용하는 것은 작성하기가 번거롭고 디버그하기가 어려우며 실제로 REST 모델을 사용하여 아무것도 구입하지 않습니다. 응용 프로그램에 하나의 진입 점이 있으면 어떤 복잡성도 얻을 수 없습니다. 이는 손실입니다. 의미있는 것을 찾기 위해 그와 같은 응용 프로그램의 로그를 탐색하려고 시도한 적이 있습니까? 그것은 할 수 있지만 차라리 내 로그에서 "방법 = 삭제"보다 "삭제"를 찾을 것입니다. 사실, 당신은 이 이미 에의 DELETE 메소드를 가지고 있다고 알리는을 알았을 때 'method = delete'가 약간 중복 된 것처럼 보입니까?웹 서버에 구현할 코드를 작성하는 이유 은 HTTP를 지원한다고 주장해야합니까? 그건 바보 야!

내 경험에 비추어 볼 때, REST API를 작성하는 것은 항상 코드가 적고 구현이 간단하며 테스트와 디버깅이 훨씬 쉬워졌습니다.

코드를 작성한 사람의 입장에서 보면, 귀하의 API는이며, 동일한 이점이 있습니다. 적은 코드, 더 간단하고 쉽게 테스트 할 수 있습니다. 내 API에 대해 문제가있는 코드 작성자와 함께 작업 할 때 문제의 원인을 파악하려면 일반적으로 'curl -XDELETE'호출의 출력을 코드 출력과 비교해야합니다. 아니, 정말로 - 그게 다야. curl이 작동하고 코드가 작동하지 않으면 일반적으로 API가 문제의 원인으로 제거됩니다.

HTTP 요청의 본문에 정보를 지저분하게 파싱하지 않습니다. 많은 경우 호출 코드가 헤더에서 가장 중요한 정보를 얻을 수 있습니다. PUT 또는 DELETE 메서드를 호출하면 주로 성공했는지 알고 싶을뿐입니다.이 경우 헤더의 HTTP 상태 코드를 읽습니다. 이 경우에도 에는 헤더 외부에서 수행 할 구문 분석이 수행되지 않으므로이 수행되므로 작업 속도가 빨라지는 부작용이 있습니다.

내가 제안한 방식으로 API를 작성한 적이 있다면, 나는 허술한 것을 이해할 수 있지만, REST를 사용하여 실제 프로덕션 응용 프로그램을 처음 배포 할 때 어리석은 제안을 발견하게 될 것입니다.

간단히 말해서 단일 진입 점은 REST API와 비교할 때 더 간단하지 않고 효율적이지 않으며 이점이 많으며 문제가 더 많습니다.

Answer 3

URL과 http 방법의 이유가 인 경우 중개인은 요청이 수행하는 작업에 대한 기본적인 이해를 허용합니다.. REST 아키텍처 스타일은 다른 구성 요소가 클라이언트와 원 서버 사이에 위치하도록하는 계층화 된 아키텍처입니다. 이러한 구성 요소는 프록시, 캐시, 방화벽,로드 균형 조정기 등 원하는 모든 것일 수 있습니다. URL은 중개자와 통신하는 방법이며 현재 수행중인 작업이며 HTTP 메서드는 사용자가 수행중인 작업의 중개자에게 기본적인 설명입니다.

URL 및 HTTP 메소드가 없으면 Squid 또는 nginx와 같은 캐시가 작동하지 않습니다.. 사용자가 액세스하려고하는 리소스를 알지 못하고 캐시 된 항목을 무효화 할시기를 알 수 없습니다.

중개자가없는 시스템을 사용하고 있다면 부작용이 거의없는 상태에서 정확하게 설명 할 수 있습니다. 그러나 중개자를 사용하지 않는다고 생각하기 전에 Windows 컴퓨터에서 을 인식하면 웹 요청은 클라이언트 컴퓨터에있는 HTTP 중개자 인 인 WinINetCache를 통해 라우팅됩니다. 다른 운영 체제가 동등한 기능을 갖고 있지 않다면 놀랄 것입니다.

계층 구성 요소 아키텍처의 사용은 REST에서 일반적으로 무시되는 부분이지만 잠재적으로 사용될 때 매우 유용 할 수 있습니다. Stack Overflow 개발자에게 문의하십시오.

또 다른 중요한 문제는 REST가 API를 만드는 것에 대한 가정을한다는 것입니다. REST는 실제로 분산 시스템을 구축하는 것에 관한 것입니다. REST 시스템에 참여할 수있는 논리 서버의 수에는 제한이 없습니다.stackoverflow 사이트를 다시 고려하면 이미지는 실제 사이트 콘텐츠가 아닌 다른 서버 세트에서 가져온 javascript 라이브러리와 다른 서버 세트에서 가져옵니다.

모든 데이터가 있어야하는 단일 종점을 정의하려면 응용 프로그램 자원을 분할하는 능력을 심각하게 제약해야합니다. RESTful 클라이언트는 시스템의 단일 진입 점에 연결하면 안되며 리소스 위치를 모르는 상태 여야하며 이전 요청시 서버가 제공 한 URL을 따라야합니다. 이를 통해 처음에는 단일 위치에서 호스트되는 분산 시스템을 개발할 수 있으며, 요구 사항이 변경되면 많은 서버로 이동 및 분리 할 수 ​​있습니다. 클라이언트가 단일 진입 점에 묶여 있으면이 작업을 수행 할 수 없습니다.