글로벌 리소스 URI (즉, 주소)의 이점은 무엇입니까?

StackOverflow https://stackoverflow.com/questions/147172

  •  02-07-2019
  •  | 
  •  

문제

Global-Unique URI를 사용하여 자원을 참조하는 것과 독점 ID 형식을 사용하는 것의 이점은 무엇입니까?

예를 들어:

  1. http://host.com/student/5
  2. http://host.com/student?id=5

첫 번째 접근 방식에서 전체 URL은 ID입니다. 두 번째 접근 방식에서는 5만이 ID입니다. 두 번째 접근 방식에 대한 첫 번째 접근 방식의 실질적인 이점은 무엇입니까?

REST가 왜 첫 번째 접근법을 옹호하는 길을 벗어나는가?

-- 편집하다:

제 질문은 실제로 두 가지 질문을했기 때문에 혼란 스러웠습니다.

  1. 주소의 이점은 무엇입니까?
  2. 위에서 볼 수있는 두 URI 형태의 차이점은 무엇입니까?

아래의 게시물을 사용하여 두 가지 질문에 모두 답변했습니다.

도움이 되었습니까?

해결책 2

나는 내 자신의 질문에 대답 할 것입니다.

1) URIS가 중요한 이유는 무엇입니까?

나는 인용 할 것이다 Leonard Richardson과 Sam Ruby의 RESTFUL 웹 서비스 (ISBN : 978-0-596-52926-0):

장르의“해파리에 대한 자원 디렉토리”에서 자원을 지명하는 실제 URI를 고려하십시오. http://www.google.com/search?q=jellyfish. 그 해파리 검색은 http://www.google.com. HTTP가 주소 지급되지 않았거나 Google 검색 엔진이 주소가 가능한 웹 응용 프로그램이 아닌 경우 해당 URI를 책에 게시 할 수 없습니다. “Google.com으로 웹 연결을 열고 검색 상자에 'jellyfish'를 입력하고 'Google 검색'버튼을 클릭하십시오.

이것은 학문적 걱정이 아닙니다. 1990 년대 중반까지 FTP : // Uris가 FTP 사이트에서 파일을 설명하는 데 인기를 얻었을 때 사람들은 다음과 같은 내용을 작성해야했습니다.“FTP.example.com에서 익명의 FTP 세션을 시작하십시오. 그런 다음 Directory Pub/ Files/로 변경하고 File.txt를 다운로드하십시오.” Uris는 FTP를 HTTP만큼 주소로 만들었습니다. 이제 사람들은 다음과 같이 씁니다.“ftp : // ftp.example.com/pub/files/file.txt를 다운로드하십시오.” 단계는 동일하지만 이제 기계로 수행 할 수 있습니다.

[...]

주소는 웹 응용 프로그램에서 가장 좋은 것 중 하나입니다. 고객이 원래 디자이너가 상상하지 못한 방식으로 웹 사이트를 쉽게 사용할 수 있습니다.

2) 주소의 이점은 무엇입니까?

서버가 제공하는 URI를 직접 구성하는 것보다 따라하는 것이 훨씬 쉽습니다. 이것은 자원 관계가 너무 복잡해지기 때문에 간단한 규칙으로 표현되기 때문에 특히 그렇습니다. 수많은 클라이언트에서 다시 구현하는 것보다 서버에서 로직을 한 번 코딩하는 것이 더 쉽습니다.

개별 리소스 URI가 변경되지 않은 상태에서도 자원 간의 관계는 변경 될 수 있습니다. 예를 들어, Google지도가 맵 타일의 규모를 변경하려면 상대 타일 위치를 계산하는 클라이언트가 파손됩니다.

3) 사용자 정의 ID에 대한 URI의 이점은 무엇입니까?

사용자 정의 ID는 리소스를 독특하게 식별합니다. Uris는 어디에서 찾을 수 있는지 알려주면서 한 걸음 더 나아갑니다. 이것은 클라이언트 로직을 단순화합니다.

다른 팁

URI가 그런 것을 볼 때 가장 중요한 것은 일반 사용자가 URI를 기억할 수 있다는 것입니다.

미국 괴짜는 물음표가 좋고 변수를 얻는다. 그러나 누군가가 기억한다면 http://www.host.com/users/john 대신에 http://www.host.com/?view=users&name=john, 그것은 큰 이점입니다.

검색 엔진 최적화 대부분.

또한 내 의견으로는 기억하기 쉽고 깨끗하고 전문적으로 보입니다.

첫 번째는 더 미적으로 즐겁습니다.

기술적으로 차이는 없지만 가능할 때 전자를 사용하십시오.

Ólafur가 언급했듯이, 이전 URL의 명확성은 하나의 이점입니다.

다른 하나는 구현 유연성입니다.

학생 5가 드물게 변한다고 가정 해 봅시다. 나머지 스타일 URL을 사용하는 경우 코드를 실행하는 대신 정적 파일을 사용하는 옵션이 있습니다. 철도에서는 학생/5에 대한 첫 번째 요청이 웹 루트 아래에 캐시 된 HTML 파일을 생성하는 것이 일반적입니다. 이 파일은 백엔드를 터치하는 후속 요청을 제공하는 데 사용됩니다. 당연히, 그 접근법에 대한 레일은 아무것도 없습니다.

이후 URL은 이것을 허용하지 않습니다. 정적 페이지의 이름에 URL 변수 (?, =)를 가질 수 없습니다.

두 URI는 휴식 관점에서 유효하지만 웹 캐시는 QueryString 매개 변수를 매우 다르게 처리한다는 것을 인식합니다.
캐싱을 유리하게 사용하려면 쿼리 문자열 매개 변수를 사용하여 리소스를 식별하지 않는 것이 좋습니다.

나는 그것이 당신이 풍수의 원리를 얼마나 밀접하게 준수하고 싶어하는지에 달려 있다고 생각합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top