RESTful URL을 사용하면 무엇을 사나요?

Question

나는 REST를 읽었으며, 그것을 사용하는 것이 어떤 이점이 있는지 알아 내려고하고있다. 특히, 쿼리 문자열을 사용하여보다 일반적인 GET 요청을 통해 구현할 가치가있는 REST 스타일 URL의 이점은 무엇입니까?

왜이 URL이된다

http://www.parts-depot.com/parts/getPart?id=00345 

이 열등 고려? (here에서 촬영) 위의 예 두 번째 URL이 실제로 더보고 우아하고 간결에서

http://www.parts-depot.com/parts/00345 

. 하지만 비용이 발생합니다 ... 첫 번째 URL은 매우 쉽게 웹 언어로 구현할 수 있습니다. 두 번째 방법은 값을 파싱하는 데 필요한 추가 코드 및/또는 서버 구성은 물론, 하위 문서 작성자에게 시스템을 설명하고 동료에게 정당화하는 데 필요한 추가 문서 및 시간을 필요로합니다.

멋지게 보이는 URL을 가지고있는 즐거움을 제외하고 구현 비용에 비견 할만한 가치가있는 RESTful URL이 얻을 수있는 이점은 무엇입니까?

Answer 1

희망 같은 XML은 당신이 만드는 경우 URL은 다음 올바르게 HTTP 동사를 구현하는 더 나은 기회가 명사를 참조한다는 것입니다. 그 외에도 한 URL과 다른 URL의 이점은 전혀 없습니다.

실제로 URL의 내용은 RESTful 시스템과 전혀 관련이 없습니다. 이것은 단순히 식별자입니다.

그것이 어떻게 생겼는지가 아니라, 중요한 일을하는 것입니다.

Answer 2

내가 항상 잘 아는 웹 사용자로서 좋아하지만 그러한 URL 스키마를 사용하는 경우 지침 원칙으로 사용해서는 안되는 것은 이러한 유형의 URL이 "해킹 가능"하다는 것입니다. 특히 "다음 페이지"버튼의 위치를 ​​찾는 대신 URL 내의 날짜 또는 페이지 번호를 편집 할 수있는 블로그와 같은 경우에 특히 유용합니다. REST 보는

Answer 3

한 가지 방법 :

(지금은 슬프게도, 아래로 옮겨졌으며,하지만 여전히 web.archive.org에서 볼 수있다) 출시와 HTTP-이 프로토콜, 어쨌든

을

http://tomayko.com/writings/rest-to-my-wife 및 그의 친구가 만든 -은 모두 에 대한 동사를 명사에 적용합니다. 예를 들어 웹 페이지로 이동하면 브라우저 은 을 입력하고 다시 웹 페이지로 연결되는 URL에 HTTP GET을 수행합니다.

은 ...

대신, 대다수는 에없는 거의 으로 유용하거나 설득력있는 다른 방법이 물건을 복잡한 사양의 바쁜 쓰기 층이다. 명사는 유니버설 및 동사가 아니며 다형성이 아닙니다. 우리는 수십 개의 실제 필드 사용을 던지고 기술을 입증하고 과 같은 것으로 시작하여 과거에 실패한 다른 시스템과 비슷하게 보입니다. 우리는 HTTP를 사용하고 있습니다. 왜냐하면 오직 이 우리 네트워크에 도움이되고 보안 사람들이 덜 필요하기 때문입니다. 우리는 번쩍 번쩍하는 도구와 마법사를 위해 단순성을 거래하고 있습니다.

Answer 4

나에게 뛰어 오는 한 가지 (좋은 질문입니다)는 그들이 설명하는 것입니다. 첫 번째는 작업 (getPart)을 설명하고 두 번째 작업은 자원을 설명합니다 (파트 00345).

또한 다른 HTTP 동사를 처음에는 사용할 수 없을 수도 있습니다. 예를 들어 putPart에 대한 새로운 방법이 필요합니다.두 번째는 리소스를 조작하기 위해 다른 동사 (PUT, DELETE, POST)와 함께 재사용 할 수 있습니까? 동사와 함께 한 번, 다시 한 번 방법으로, 두 번째가 HTTP 프로토콜의 의도와 더 일치하도록 두 번 GET을한다고 말하는 것 같아요?

Answer 5

정말

"두 번째는, 추가 코드 및/또는 서버 구성 값에서 을 구문 분석이 필요합니다"? 그런 다음 가난한 프레임 워크를 선택합니다. 내 경험에 따르면 RESTful 버전은 정확히 같은 양의 코드이다. 어쩌면 나는 멋진 프레임 워크를 보았을 것입니다.

"뿐만 아니라 추가 문서 와 시간이 주니어 프로그래머 시스템 을 설명 보냈다"한 번만

. 그들이 그것을 얻은 후에, 당신은 그것을 다시 설명하지 않아야합니다.

"그리고 그것을 동료들에게 정당화한다."

한 번만. 그들이 그것을 얻은 후에, 당신은 그것을 다시 설명하지 않아야합니다.

Answer 6

REST IMO의 가장 큰 장점은 REST 서비스에서 가장 중요한 HTTP 동사를 사용할 수 있다는 점입니다. 사실, REST를 사용한다는 것은 HTTP 프로토콜과 그 동사를 사용하고 있다는 것을 의미합니다.

다음과 같이해야한다 대신

첫 번째 경우를 얻는, URL을 사용하여, 당신은 "일부"를 게시 할 상상 : 당신은 당신이 게시물을 사용한해야 GET을 사용하는

http://www.parts-depot.com/parts/postPart?param1=lalala&param2=lelele&param3=lilili 

지내는 컨텍스트 동안,

http://www.parts-depot.com/parts 

반드시 a 차 몸에, (예를 들어)이

<part> 
    <param1>lalala<param1> 
    <param2>lelele<param1> 
    <param3>lilili<param1> 
</part> 

Answer 7

URI의 의미는 RFC 2396으로 정의됩니다. 특히이 문제와 관련된 추출물은 3.3이다. "경로 성분"

경로 성분은 그 방식과 권한의 범위 내에 자원 식별 데이터 (어떤 권한 성분이없는 경우 또는 방식) 권한 특정을 포함한다.

그리고 3.4 "쿼리 구성 요소"

쿼리 구성 요소는 정보의 문자열 자원에 의해 해석되어야한다.

쿼리 구성 요소는 리소스 식별자의 일부가 아니며 단지 리소스로 해석되는 정보에 불과하다는 점에 유의하십시오.

이와 같이, 첫 번째 예에서 식별되는 리소스는 실제로는 단지 /parts/getPart입니다. URL이 하나의 특정 파트 리소스를 식별해야한다는 의도라면 첫 번째 예제에서는이를 수행하지 않지만 두 번째 예제에서는 수행하지 않습니다 (/parts/00345).

URL의 두 번째 스타일의 '장점'은 의미 상 정확하다는 것입니다. 반면 첫 번째 스타일은 의미가 없습니다.

Answer 8

URL 스펙에 따라 쿼리 또는 검색이 아닌 URL에서 쿼리/검색 부분을 사용하지 마십시오. 원하지 않는 리소스에 대해 뭔가 의미가있을 수 있습니다.

더 큰 리소스의 하위 집합 인 리소스에 대해 쿼리 파트를 사용합니다. 페이지 매김이 적용될 수있는 좋은 예입니다.