분명히 REST는 HTTP 사용 방법에 대한 일련의 규칙 일뿐 입니다. 이 협약이 어떤 이점을 제공하는지 궁금합니다. 아는 사람 있나요?
답변:
REST 가 무엇인지 실제로 아무도 아무도 동의하지 않기 때문에 이것에 대한 좋은 대답을 얻지 못할 것이라고 생각합니다 . 위키 피 디아 페이지는 전문 용어 무거운 및 설명에 빛입니다. 토론 페이지는 사람들이 이것에 얼마나 동의하지 않는지 살펴볼 가치가 있습니다. 그러나 내가 알 수있는 한 REST는 다음을 의미합니다.
대신 무작위로 이름 세터와 게터 URL을 갖고 사용하는 GET모든 게터과 POST세터 모두를 위해, 우리는 URL이 자원을 식별하도록 시도하고 HTTP 작업을 사용 GET, POST, PUT그리고 DELETE그들에게 물건을 할 수 있습니다. 그래서 대신
GET /get_article?id=1
POST /delete_article id=1
당신은 할 것
GET /articles/1/
DELETE /articles/1/
그리고 그 POST와 PUT대응 "을 만들"와 "갱신"작업 (하지만 아무도 어떤 방법 내내 동의하지 않음)에.
캐싱 인수는 일반적으로 캐시 되므로 일반적으로 캐시 문자열 을 사용할 필요 가 없기 때문에 캐싱 인수가 잘못되었다고 생각 합니다. 예를 들어 django는 이와 같은 것을 매우 쉽게 만들고 REST라고 말하지 않습니다.
GET /get_article/1/
POST /delete_article/ id=1
또는 URL에 동사를 포함 시키십시오.
GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/
이 경우 GET부작용이없는 POST것을 의미하며 서버의 데이터를 변경하는 것을 의미합니다. 난 당신이 전체 피할 수 특히,이 아마 조금 명확하고 쉽게 생각 PUT일등석 POST일을. 또한 원하는 경우 동사를 더 추가 할 수 있으므로 HTTP가 제공하는 기능에 인위적으로 구속되지 않습니다. 예를 들면 다음과 같습니다.
POST /hide/article/1/
POST /show/article/1/
(또는 어쨌든 예제가 발생할 때까지 생각하기가 어렵습니다!)
결론적으로 볼 수있는 장점은 두 가지뿐입니다.
synchronize("/articles/1/")하거나 무엇이든 할 수 있기 때문에 REST를 사용하는 것이 더 쉽습니다 . 이것은 코드에 크게 의존합니다.그러나 나는 꽤 큰 단점이 있다고 생각합니다.
PUT하고 POST있습니다. 영어로 그들은 비슷한 것을 의미합니다 ( "나는 벽에 통지를 게시 / 게시 할 것입니다.").결론적으로 말하면 : 추가 노력을 기울이고 싶지 않거나 서비스가 CRUD 작업에 실제로 매핑되지 않으면 API의 두 번째 버전에 대해 REST를 저장하십시오.
방금 REST와 관련하여 또 다른 문제가 발생했습니다. 한 요청에서 둘 이상의 작업을 수행하거나 복합 객체의 일부를 가져 오려는 것을 지정하는 것은 쉽지 않습니다. 이는 왕복 시간이 중요하고 연결을 신뢰할 수없는 모바일에서 특히 중요합니다. 예를 들어, 페이스 북 타임 라인에 게시물을 받고 있다고 가정합니다. "순수한"REST 방식은 다음과 같습니다.
GET /timeline_posts // Returns a list of post IDs.
GET /timeline_posts/1/ // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....
어리석은 일입니다. Facebook의 API는 매우 훌륭한 IMO이므로 그들이하는 일을 봅시다 :
기본적으로 쿼리 할 때 대부분의 개체 속성이 반환됩니다. "fields"쿼리 매개 변수를 사용하여 리턴 할 필드 (또는 연결)를 선택할 수 있습니다. 예를 들어이 URL은 Ben의 ID, 이름 및 사진 만 반환합니다. https://graph.facebook.com/bgolub?fields=id,name,picture
REST로 어떻게 그런 일을하는지 전혀 알지 못하며 여전히 REST로 계산되는지 여부를 알 수 있습니다. 나는 당신이 그렇게하지 말아야한다고 말하려고하는 누군가를 확실히 무시할 것입니다 (특히 이유가 "휴식이 아니기 때문에")!
간단히 말해, REST는 HTTP를 원래대로 사용하는 것을 의미합니다.
REST에 대한 Roy Fielding의 논문을 살펴보십시오 . 나는 웹 개발을하는 모든 사람이 그것을 읽어야한다고 생각합니다.
참고로 Roy Fielding은 HTTP 프로토콜의 핵심 드라이버 중 하나입니다.
advandages의 이름을 지정하려면 :
간단히 말해서 : NONE .
공감할 수는 있지만, 비 REST HTTP에 비해 실질적인 이점은 없다고 생각합니다. 모든 현재 답변이 유효하지 않습니다. 현재 가장 많이 투표 된 답변의 인수 :
REST를 사용하면 서버 측 및 클라이언트 측 스크립트에 대한 추가 통신 계층이 필요합니다. => 실제로 비 REST HTTP를 사용하는 것보다 더 복잡합니다.
캐싱은 서버가 보낸 HTTP 헤더로 제어 할 수 있습니다. REST는 비 REST에서 누락 된 기능을 추가하지 않습니다.
REST는 사물 정리에 도움 이 되지 않습니다 . 그것은 강제로 사용중인 서버 측 라이브러리가 지원하는 API를 사용합니다. 비 REST 접근 방식을 사용할 때 응용 프로그램을 같은 방식으로 구성 할 수 있습니다. 예를 들어 Model-View-Controller 또는 MVC 라우팅을 참조하십시오 .
전혀 사실이 아닙니다. 이 모든 것은 응용 프로그램을 얼마나 잘 구성하고 문서화하는지에 달려 있습니다. REST는 마술처럼 애플리케이션을 향상시키지 않습니다.
REST가 가능하게하는 가장 큰 장점은 클라이언트 / 서버 커플 링을 줄이는 것입니다. 기존 클라이언트를 중단하지 않고 시간이 지남에 따라 REST 인터페이스를 발전시키는 것이 훨씬 쉽습니다.
각 리소스에는 계층 또는 링크의 다른 리소스에 대한 참조가 있으므로 쉽게 찾을 수 있습니다. 이는 사람이 클라이언트를 개발하여 문서를 지속적으로 컨설팅하지 않아도되고 제안을 제공하는 데 유리합니다. 또한 클라이언트 소프트웨어가 URL을 하드 코딩하지 않는 한 서버가 자원 이름을 일방적으로 변경할 수 있음을 의미합니다.
API의 어느 부분으로나 갈 수 있거나 웹 브라우저를 사용하여 리소스를 탐색 할 수 있습니다. 디버깅 및 테스트 통합이 훨씬 쉬워집니다.
올바른 단어를 찾지 않고도 작업을 지정할 수 있습니다. OOP의 getter 및 setter가 표준화되지 않은, 어떤 사람들이 사용 된 경우 상상 retrieve하고 define대신. 각 개별 액세스 포인트에 대해 올바른 동사를 기억해야합니다. 사용 가능한 소수의 동사가 그 문제에 불과하다는 것을 아는 것.
GET존재하지 않는 리소스 인 경우 404RESTful API에 오류가 발생할 수 있습니다 . 그것을 REST가 아닌 API와 대조하십시오 {error: "Not found"}. 다른 쪽 개발자에게 메시지를 작성하기 위해 추가 공간이 필요한 경우 언제든지 응답 본문을 사용할 수 있습니다.
동일한 기능을 가진 두 개의 API를 상상해보십시오. 하나는 REST를 따르고 다른 하나는 그렇지 않습니다. 이제 해당 API에 대해 다음 클라이언트를 상상하십시오.
평안한:
GET /products/1052/reviews
POST /products/1052/reviews "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10
HTTP :
GET /reviews?product_id=1052
POST /post_review?product_id=1052 "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10
이제 다음 질문들을 생각해보십시오.
각 고객의 첫 번째 전화가 효과가 있었다면 나머지는 어떻게 작동 할 수 있습니까?
액세스 포인트가 변경되었거나 변경되지 않은 API에 대한 주요 업데이트가있었습니다. 얼마나 많은 문서를 다시 읽어야합니까?
마지막 쿼리의 반환을 예측할 수 있습니까?
게시 된 검토를 삭제하기 전에 편집해야합니다. 문서를 확인하지 않고도 할 수 있습니까?
Ryan Tomayko의 아내에게 REST를 설명하는 방법을 살펴 보는 것이 좋습니다.
waybackmaschine 링크에서 발췌 :
예는 어떻습니까. 당신은 교사이고 학생들을 관리하기를 원합니다 :
시스템이 웹 기반 인 경우 여기에 관련된 각 명사에 대한 URL이있을 수 있습니다 student, teacher, class, book, room, etc. ... 각 URL에 대해 기계가 읽을 수있는 표현이 있다면, 모든 정보가 표준 방식으로 소비 될 수 있기 때문에 새로운 도구를 시스템에 걸치는 것은 사소한 일입니다. ... 당신은 시험 점수를 수집하기 위해 각 개별 학교 시스템과 대화 할 수있는 전국 시스템을 구축 할 수 있습니다.
각 시스템은 간단한 HTTP GET을 사용하여 서로 정보를 얻습니다. 한 시스템이 다른 시스템에 무언가를 추가해야하는 경우 HTTP POST를 사용합니다. 시스템이 다른 시스템에서 무언가를 업데이트하려면 HTTP PUT을 사용합니다. 알아 내야 할 유일한 것은 데이터의 모습입니다.
나는이 질문에 대한 답을 찾고있는 모든 사람들 이이 "슬라이드 쇼"를 진행할 것을 제안 합니다.
REST가 무엇인지, 왜 그렇게 멋진 지, 장단점, SOAP과의 차이점을 이해할 수 없었습니다. 그러나이 슬라이드 쇼는 매우 훌륭하고 이해하기 쉽기 때문에 지금보다 훨씬 더 명확합니다.
캐싱.
느슨한 커플 링 및 하이퍼 텍스트를 통한 진화 가능성을 중심으로하는 REST의 또 다른 깊이있는 이점이 있지만 캐싱 메커니즘이 RESTful HTTP에 관심을 가져야하는 주된 이유입니다.
GET /get_article/19/및 POST /update_article캐싱 우려가있는 경우. 당신은 여전히 함께 모든 것을 할 수 GET와 POST나는 믿는다 REST"사용 방법을 GET, POST, PUT그리고 DELETE만." "쿼리 문자열을 사용하지 마십시오." 그래서 내가 제안한 것은 아닙니다 REST. 그럼 다시, 아무도 정말 무엇에 동의 할 수 없다 REST 이다 나는 "웹 2.0"로 양동이에 넣어거야, 그래서.
Fielding 논문 에 작성되었습니다 . 그러나 많이 읽고 싶지 않다면 :
POST와 GET만으로 모든 것을 할 수 있습니까? 예, 가장 좋은 방법입니까? 이유없이? 표준 방법이 있기 때문입니다. 다시 생각하면 GET 만 사용하여 모든 작업을 수행 할 수 있습니다. 왜 POST를 사용해야합니까? 표준 때문에!
예를 들어, 오늘날 MVC 모델을 생각하면 POST, GET, PUT 및 DELETE와 같은 특정 종류의 동사에만 응답하도록 응용 프로그램을 제한 할 수 있습니다. 후드 아래에서 모든 것이 POST와 GET으로 에뮬레이트 되더라도 다른 동작에 대해 다른 동사를 갖는 것이 합리적이지 않습니까?
REST에서 발견이 훨씬 쉽습니다. 귀사의 서비스를 전세계에 알리는 데 도움이되는 WADL 문서 (전통적인 웹 서비스의 WSDL과 유사)가 있습니다. UDDI 발견도 사용할 수 있습니다. 전통적인 HTTP POST 및 GET을 사용하면 사람들이 귀하의 메시지 요청 및 응답 스키마를 모를 수도 있습니다.
@Timmmm, 편집 내용 :
GET /timeline_posts // could return the N first posts, with links to fetch the next/previous N posts
이것은 통화 수를 크게 줄입니다.
그리고 클라이언트가 원하는 필드 값을 표시하기 위해 HTTP 매개 변수를 허용하는 서버를 설계하는 것을 막을 수있는 것은 없습니다.
그러나 이것은 세부 사항입니다.
REST 아키텍처 스타일의 큰 장점을 언급하지 않았다는 사실이 훨씬 더 중요합니다. 예를 들어 REST 아키텍처 스타일을 사용하는 경우, 균일 한 인터페이스 사용으로 인해 클라이언트와 서버 간의 연결이 훨씬 낮아짐 등)
발언은
"모든 작업이 CRUD (만들기, 읽기 / 검색, 업데이트, 삭제)에 쉽게 매핑되는 것은 아닙니다."
: RDBMS는 CRUD 접근 방식 (SELECT / INSERT / DELETE / UPDATE)도 사용하며, 항상 데이터 모델을 표현하고 수행하는 방법이 있습니다.
당신의 문장에 대하여
"객체 유형 리소스를 다루지 않을 수도 있습니다"
: RESTful 디자인은 본질적으로 단순한 디자인이지만 디자인이 단순하다는 것을 의미하지는 않습니다. 차이가 보입니까? 리소스를 통해이를 표현하기 위해 응용 프로그램이 표현하고 처리 할 개념, 원하는 경우 수행해야하는 개념에 대해 많이 생각해야합니다. 그러나 그렇게하면 더 단순하고 효율적인 디자인이됩니다.
검색 엔진은 쿼리 문자열을 무시할 수 있습니다.