RESTful API에서 슬래시


60

RESTful API에서 슬래시로 무엇을해야하는지에 대한 토론이있었습니다.

개라고하는 자원과 개별 개를위한 종속 자원이 있다고 가정하겠습니다. 따라서 다음을 수행 할 수 있습니다.

GET/PUT/POST/DELETE http://example.com/dogs
GET/PUT/POST/DELETE http://example.com/dogs/{id}

그러나 우리는 다음과 같은 특별한 경우로 무엇을합니까?

GET/PUT/POST/DELETE http://example.com/dogs/

내 개인적인 견해는 이것이 id =로 개별 개 자원에 요청을 보내는 것 null입니다. 이 경우 API가 404를 반환해야한다고 생각합니다.

다른 사람들은 요청이 개 자원에 액세스하고 있다고 말합니다. 즉, 후행 슬래시는 무시됩니다.

누구든지 확실한 대답을 알고 있습니까?


2
나는 RESTful 방법이 개 / 개와 개를 구별하는 것이라고 생각했습니다 (모든 개를 의미).
pdr

RESTful 웹 서비스-종속 자원 : 다른 "부모"자원과 관련하여 존재하는 자원 (예 : dogs / {id})에서 웹 사용 데이터베이스는 테이블을 자원으로, 개별 데이터베이스 행을 종속 자원으로 노출 할 수 있습니다. .
Gaz_Edge

개 자원에 액세스 중입니다. 후행 슬래시는 무시해야합니다. 즉, 삭제를 적용하지 않아야하는 항목을 삭제하려고 시도하면 금지 된 응답을 받아야합니다. 404도 괜찮습니다. 그래도 문제가 되나요?
벤자민 Gruenbaum

나는 따라하지 않습니다-누가 개를 삭제할 수 없다고 말했습니까? 개를 삭제하면 자체 개와 모든 개별 개가 삭제됩니다. 그래서 개를 부르는 것이 위험하다고 생각하는 이유입니다. 고객이 개별 개를 삭제하려고했지만 실수로 {id}를 중단 한 경우 결과적으로 모든 개가 삭제됩니다. {id} null을 요구하고 404를 반환한다고 가정하는 것이 훨씬 안전합니다.
Gaz_Edge

나는 치료하는 것 dogsdogs/같은 동등한. 저에게는 dogs/개가 들어있는 디렉토리 라는 것이 분명합니다 . 명확하지 않지만 dogs대부분의 웹 서버가 후행없이 디렉토리에 대한 액세스를 허용하는 것처럼 동등한 것으로 취급합니다 /.
코드 InChaos

답변:


50

REST가 정확한 의미를 갖지 않기 때문에이 중 어느 것도 신뢰할 수 없습니다. 그러나 REST의 원래 논문에서 전체 (/로 끝나지 않는) URL은 자원 이름을 지정하고 슬래시 '/'로 끝나는 URL은 자원 그룹 (아마도 그렇게 말하지 않음)입니다.

끝에 슬래시가있는 URL의 GET은 사용 가능한 자원을 나열합니다.

GET http://example.com/dogs/          /* List all the dogs resources */

슬래시가있는 URL의 PUT은 모든 자원을 대체해야합니다.

PUT http://example.com/dogs/          /* Replace all the dogs resources */

슬래시가있는 URL에서 삭제하면 모든 자원이 삭제됩니다.

DELETE http://example.com/dogs/       /* Deletes all the dogs resources */

슬래시가있는 URL의 POST는 새 리소스를 생성 한 다음 액세스 할 수 있습니다. 새로운 리소스는이 디렉토리에 있어야합니다 (여기에는 많은 RESTful 아키텍처가 속임수이지만).

POST http://example.com/dogs/        /* Creates a new dogs resource (notice singular) */

기타

주제에 대한 위키 페이지에서 잘 설명하는 것 같습니다.

https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_Web_services 예제를 참조하십시오 .


또한 디렉토리가 종종 후행 작성하는 정상 경로 / URL 모델을 맞는/
CodesInChaos

4
따라서 후행없이 자원 그룹에 액세스하면 /어떻게됩니까?
준수

1
@oberlies : 상황에 따라 다릅니다. 최선의 방법은 단단하고 빠른 규칙이 없습니다. 규칙에는 항상 expcetions가 있으며 규칙의 의미를 의미해야합니다. 위의 예에서 : GET http://example.com/dogs개에 대한 메타 정보 (목록 자체가 아니라 개 목록에 대한 메타 정보)를 반환 할 수 있습니다. 어쩌면 오류 일 수 있습니다.
Martin York

1
As the last character within a URI’s path, a forward slash (/) adds no semantic value and may cause confusion. It’s better to drop them completely.훈련 슬래시를 사용하지 말 것을 제안 하는 유일한 은 아닙니다
Laiv

@Laiv 나는 정서에 동의하지 않습니다. 그러나 더 권위있는 참조를 연결하십시오 (약한 연결입니다).
Martin York

17
Does anyone know the definitive answer?

RESTful로 간주되는 서비스에 필요한 공식 문서가 없기 때문에 하나도 없습니다.

그것은 단순히 사용하기 쉽도록 슬래시를 허용 할 것이라고 말했습니다. 기술적으로 말하면 이것은 null ID로 개에 액세스하려고 시도하는 것으로 볼 수 있습니다. 사용자가 설명서에서 읽지 않는 한이 점프를하는 사용자를 보지 못했습니다. 사용자가 API에 대해 코드를 작성하려고 시도하고 습관에서 단순히 슬래시를 포함하고 그들이 개 목록을 원할 때 왜 404 응답을 얻는 지 궁금합니다.


DELETE example.com/dogs는 어떻습니까?
벤자민 Gruenbaum

개는 모든 개의 부모이므로 개를 삭제하면 모든 개와 그 자체가 삭제됩니다. 그렇게하지 않으면 하이퍼 미디어가 고장납니다
Gaz_Edge

@Gaz_Edge : REST example.com/dogs에서 리소스는 리소스와 완전히 독립적 인 리소스 example.com/dogs/X입니다. 따라서 DELETE on example.com/dogs은 모든 개 / *를 삭제할 필요는 없습니다 (시맨틱 인 경우 가능할 수 있음). 그러나 DELETE example.com/dogs/는 모든 개 / *를 삭제 해야합니다.
Martin York

3
RESTful이 무엇인지에 대한 결정적인 규칙이 없기 때문에 / dogs 또는 / dogs /를 삭제할 때 발생하는 일이 API 소비자가 기대하는 것을 기반으로 할 것이라고 다시 한 번 말하고 싶습니다. 실제로 한 번의 요청으로 모든 개를 삭제하고 싶습니까? 그렇다면 그런 식으로 구현하고, 그렇지 않으면 405 Method Not Allowed 응답을 제공하십시오.
Mike

1
나는 이것이 오래된 실이라는 것을 알고 있지만 최근에 이것에 대해 궁금해하고 있습니다. 것이 가치가 무엇인지, 운영체제 X 배쉬 쉘 취급 foo, foo/foo////동일. 기본적으로 빈 경로 세그먼트를 제거하는 것 같습니다. 그래서, 당신은 당신의 REST 서비스와 같은 접근 방식을 따르 경우 dogsdogs/같은 일을 참조한다.
Greg Brown

2

두 가지 방법.

방법 1

자식을 포함 할 수있는 모든 리소스에는 항상 슬래시를 사용하십시오.

파일이있는 public_html 디렉토리에서 "GET"을 고려하십시오.

hello.html이 파일 인 경우 불가능합니다 :

/hello.html
/hello.html/youagain.html

그러나 hello.html이 디렉토리 인 경우 가능합니다.

/hello.html/     (actually /hello.html/index.html)
/hello.html/youagain.html

"hello.html"에 자식이있을 수 있다면 항상 "/hello.html/"이고 "/hello.html/index.html"(또는 간단히 /hello.html/)은이 자식의 목록입니다 .

방법 2

"똑똑하다".

$ find
.
./hello.html
./hello.html/index.html

find 명령은 hello.html 유형에 신경 쓰지 않습니다. 관심있는 디렉토리 또는 파일은 객체의 이름입니다. "cp youagain.html hello.html"을 작성할 때 cp는 hello.html을 처리하는 방법을 알아낼 수 있습니다. cp는 똑똑하다. 웹 서버도 똑똑합니다. 경로 처리 라이브러리가 있습니다. 라우팅이 있습니다. 이름이 객체인지 디렉토리인지를 말하고 알려줄 수 있습니다. blah를 blah /로 리디렉션하거나 둘 다에 대해 동일한 응답을 제공 할 수도 있습니다. 대단해 !!! 방법. 너무 많은 기술. 우리가 그 모든 것을 할 수있을 때 누가 단순히 경로 문자열을 연결하고 싶습니까 ???

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.