2009-04-02 2 views
4

Flickr은 XML-RPC와 REST 방식을 제공합니다.대부분의 웹 서비스가 REST 스타일로 된 이유는 무엇이며 XML-RPC에서도 그렇지 않은 이유는 무엇입니까?

모든 언어에 대해 표준 XML-RPC 라이브러리가 있습니다 (예 : Python에는 xmlrpclib이 내장되어 있습니다).

표준 XML-RPC 라이브러리는 직렬화/역 직렬화 및 응답 송수신을 담당합니다.

동일한 API에 대해 REST 스타일을 사용하는 웹 사이트는 결국 각 언어로 자체 라이브러리를 작성하게됩니다. 예 : Yahoo! SDK 검색.

나에게는 XML-RPC 방법이 더 나은 것으로 보이지만 모든 증거는 반대로 있습니다. 왜?

그래서 :

  1. 왜 XML-RPC에서 대부분의 웹 REST 스타일 서비스, 그리고 무엇입니까?
  2. 명백하지 않은 XML-RPC의 단점이 있습니까?
+0

Roy T. Fielding : "Flickr는 REST가 HTTP의 별칭으로 사용했기 때문에 분명히 단서가 없습니다. 아마도 Wikipedia 항목도 혼란 스럽기 때문일 수 있습니다." – aehlke

답변

0

간단한 답변 : REST는

+0

클라이언트 또는 서버의 경우? 그것이 서버라면, 나는 또한 꽤 표준화되어 있다고 생각한다. - http://docs.python.org/library/simplexmlrpcserver.html 그렇지 않습니까? –

+1

정말인가요? RESTful 웹 서비스에 대한 * 책의 공동 저자가 Amazon에서 작동하더라도 Amazon의 소위 REST 서비스는 RESTful이 아닙니다. Flickr의 "REST"웹 서비스는 RESTful이 아닙니다. Ruby on Rails의 "REST"인터페이스는 RESTful이 아닙니다. 그것은 나에게 매우 쉽게 보이지 않습니다. –

+1

로이 필딩 (Roy Fielding)은 최근에 REST가 단순한 디자인이기 때문에 디자인하는 것이 간단하지 않다는 블로그 기사를 작성했습니다. 실제로 이것은 디자인의 기본 법칙 중 하나입니다. 디자인이 단순할수록 작업이 많습니다. –

4
  1. 나머지는 그냥 그 훨씬 쉽게 쉽게되지 않습니다 구현하기 쉬운 경향이있다.

  2. XML-RPC는/비누
    과 달리 필요하지 않은 (자주)인지 움직이는 부품의 많은 오버 헤드의 상당한 양을 가지고, 그 복잡하고 당신은 특별히 몇 가지 기능이 필요 하지 않는 한 잘 정의되어 공식적인 시스템 및 을 대표하는 개를위한 훌륭한 모델도 그냥이

  3. 아니 모든 서비스 요청이 매개 변수

  4. REST와 정식 함수 호출로 패키지화 할 필요가 없습니다 가치 제공 자원 웹 (따라서 용어 REST) ​​

볼 ES는 그렇게 먼저 사용하는 방법에 대한 주위 구글 REST를 사용하여 초보자 많은 실수를 쉽게 만들 수 있다고 말해 두 겠는데, 당신은 당신이 한 드리겠습니다 .

+0

REST가 쉬우므로 동의하지 않습니다. 나는 REST를 올바르게 사용하는 사람을 거의 보지 못했다. – aehlke

-1

웹에서 많은 토론이 있으므로 답변에 대해 자세히 설명하지 않겠습니다. 요약하면 쉽습니다. 쓰기 쉽고, 이해하기 쉽고, 디버그하기 쉽습니다. 당신은 당신의 브라우저에 그것을 쓸 수 있으며, 아마 뭔가 도움이 될 것입니다. 아주 좋아.

이 용이성은 "가능성"이 적어 지지만 이론은 장기적으로 볼 때 쉽게 실현할 수 있습니다.

+0

"브라우저에 [URL]을 쓸 수 있습니다. 그러면 아마도 도움이 될 것입니다." +1 – Lucas

+0

이것은 말도 안되는 일입니다. 죄송합니다. 그게 무슨 뜻이야? 브라우저 지원에서 URI를 입력하는 유일한 방법은 GET 메소드입니다. 그리고 이것은 REST와는 전혀 관련이 없습니다. – aehlke

+0

위키 백과 (http://en.wikipedia.org/wiki/Representational_State_Transfer)에서 REST를 확인하십시오. 나머지는 HTTP를 사용합니다 (웹과 관련이 없지만). GET입니다. REST는 매우 간단합니다. 리소스와 요청 매개 변수를 함께 사용하는 것이 좋습니다. 분명히 그것 뒤에 몇 가지 의제가 있지만, 이것이 주요 포인트입니다. 그래서 request.com/user/lior를 사용하는 대신 request.com/user/lior를 사용하여 내 사용자에 대해 작업하고 GET이 정보를 얻으면 POST는 새 사용자 [http] DELETE를 설정합니다. 그것을 삭제하십시오 etc. 죄송합니다 당신에게 말도 안되는 소리지만, 그게 휴식이야. – Liorsion

1

위대한 질문입니다. 검색 및 표준 미디어 형식에 대해 하이퍼 미디어를 활용하지 않는 한 REST의 이점을 얻지 못할 가능성이 높습니다. 당신은 XML-RPC를 고수 할 수도 있습니다.

-1

REST는 웹의 기본 아키텍처 스타일입니다. XML-RPC와 SOAP은 매우 다른 (절차 적, 필수적) 프로그래밍 모델을 채택하여 웹에 적용하려고 시도합니다. 결과적으로 REST는 더 깔끔하고 유연 해집니다.

+0

이것은 완전히 잘못되었습니다. REST는 프로토콜 독립적이며 특별히 웹에 관한 것은 아닙니다. "웹의 네이티브 아키텍처 스타일"은 HTTP 일 뿐이며 HTTP를 올바르게 사용해도 RESTful이 아님을 의미하지는 않습니다. – aehlke

관련 문제