가장 좋은 / 일반적인 RESTful URL 동사 및 작업은 무엇입니까?

가장 좋고 가장 일반적인 RESTful URL 작업에 대한 정보를 찾으려고합니다.

예를 들어 항목의 세부 정보를 표시하고 항목을 편집하고 업데이트하는 데 어떤 URL을 사용합니까?

/question/show/<whatever>
/question/edit/<whatever>
/question/update/<whatever> (this is the post back url)
/question/list   (lists the questions)

흠. 도와 주신 분들께 감사드립니다 :)

URL을 사용하여 작업이 아닌 개체를 지정합니다.

처음 언급 한 내용은 RESTful이 아닙니다.

/questions/show/<whatever>

대신 URL을 사용하여 객체를 지정해야합니다.

/questions/<question>

그런 다음 해당 리소스에 대해 아래 작업 중 하나를 수행합니다.

가져 오기:

리소스를 얻고, 리소스 목록을 쿼리하고, 리소스에 대한 읽기 전용 정보를 쿼리하는 데 사용됩니다.

질문 리소스를 얻으려면 :

GET /questions/<question> HTTP/1.1
Host: whateverblahblah.com

모든 질문 리소스를 나열하려면 :

GET /questions HTTP/1.1
Host: whateverblahblah.com

게시하다:

리소스를 만드는 데 사용됩니다.

다음은 오류입니다.

POST /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

URL이 아직 생성되지 않은 경우 이름을 지정하는 동안 POST를 사용하여 생성해서는 안됩니다. 아직 존재하지 않기 때문에 리소스를 찾을 수 없음 오류가 발생합니다. 먼저 서버에 리소스를 넣어야합니다. 새 질문을 만들면 이제 질문 목록에 하나 이상의 질문을 반환하므로 / questions 리소스도 업데이트한다고 주장 할 수 있습니다.

POST를 사용하여 리소스를 생성하려면 다음과 같이해야합니다.

POST /questions HTTP/1.1
Host: whateverblahblah.com

이 경우 리소스 이름이 지정되지 않으면 새 개체 URL 경로가 반환됩니다.

지우다:

리소스를 삭제하는 데 사용됩니다.

DELETE /questions/<question> HTTP/1.1
Host: whateverblahblah.com

놓다:

리소스 URL을 지정하는 동안 리소스를 만들거나 덮어 쓰는 데 사용됩니다.

새 리소스의 경우 :

PUT /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

기존 리소스를 덮어 쓰려면 :

PUT /questions/<existing_question> HTTP/1.1
Host: whateverblahblah.com

... 예, 동일합니다. PUT는 종종 전체 리소스를 약간 변경된 버전으로 대체하여 클라이언트가 다음에 수행 할 때 얻을 수있는 내용을 편집했기 때문에 '편집'방법으로 설명됩니다.

HTML 양식에서 REST 사용 :

HTML5 스펙을 정의 GET 양식 요소에 대한 POST .

메소드 컨텐츠 속성은 다음 키워드 및 상태가있는 열거 속성입니다.

• HTTP GET 메소드를 나타내는 GET 상태에 맵핑되는 키워드 GET.
• HTTP POST 메서드를 나타내는 POST 상태에 매핑되는 키워드 POST입니다.

기술적으로 HTTP 사양은 이러한 방법으로 만 제한되지 않습니다. 기술적으로 원하는 방법을 자유롭게 추가 할 수 있지만 실제로는 좋은 생각이 아닙니다. 아이디어는 모든 사람이 GET을 사용하여 데이터를 읽는다는 것을 알고 있으므로 대신 READ를 사용하기로 결정하면 문제가 발생합니다. 그 말은 ...

반점:

이것은 공식 RFC에서 정의 된 방법입니다. 리소스에 부분 수정 만 보내려는 경우에 사용하도록 설계되었으며 PUT와 매우 유사하게 사용됩니다.

PATCH /questions/<new_question> HTTP/1.1
Host: whateverblahblah.com

차이점은 PUT은 실제로 변경된 내용과 비교하여 얼마나 큰지에 관계없이 전체 리소스를 보내야하는 반면 PATCH 는 변경 사항 만 보낼 수 있다는 것 입니다.

/questions/10유효한 질문 이라고 가정하면 방법이 상호 작용하는 데 사용됩니다.

추가 할 POST

생성 또는 교체를위한 PUT

보기 / 쿼리하기

잘 삭제합니다 .. 삭제합니다.

URL은 변경되지 않습니다.

나는 팔다리로 나가서 "RESTful"URL을 말할 때 MVC의 표준 컨트롤러가 무엇인지 짐작할 것입니다. 예제는 "RESTful" 이 아닌 것으로 간주 될 수 있기 때문입니다 ( 이 기사 참조).

Rails가 관심있는 것으로 보이는 URL 스타일을 실제로 대중화했기 때문에 Ruby on Rails 의 ScaffoldingGenerator 에서 생성 한 기본 컨트롤러 작업을 아래에 제공합니다 . Rails 애플리케이션을 사용하는 사람이라면 누구나 익숙 할 것입니다.

스캐 폴딩 된 작업 및보기는 다음과 같습니다. index, list, show, new, create, edit, update, destroy

일반적으로 다음과 같이 구성합니다.

http://application.com/controller/<action>/<id>

다음은 REST 원칙을 사용하는 현재 URL의 매핑입니다.

/question/show/<whatever>

질문을 리소스로 식별하는 경우 고유 URL이 있어야합니다. GET을 사용하여 표시 (검색)하는 것이 일반적인 관행입니다. 다음과 같이됩니다.

GET /question/<whatever>

/question/edit/<whatever>

이제 사용자가 리소스를 편집 할 수 있도록 동일한 리소스에 대한 다른보기를 갖기를 원합니다 (양식 컨트롤을 사용할 수 있음).

여기에 두 가지 옵션이 있습니다. 응용 프로그램은 웹 사이트가 아닌 응용 프로그램이므로 JavaScript를 사용하여 클라이언트 측에서 리소스를 편집 가능한 리소스로 변환하는 것이 좋습니다.

웹 사이트 인 경우 추가 정보와 함께 동일한 URL을 사용하여 다른보기를 지정할 수 있습니다. 일반적인 관행은 다음과 같습니다.

GET /question/<whatever>;edit

/question/update/<whatever> (this is the post back url)

이것은 질문을 변경하는 것이므로 PUT이 올바른 사용 방법입니다.

PUT /question/<whatever>

/question/list   (lists the questions)

질문 목록은 실제로 질문의 상위 리소스이므로 당연히 다음과 같습니다.

GET /question

이제 더 필요할 수 있습니다.

POST /question (create a new question and returns its URL)
DELETE /question/<whatever> (deletes a question if this is relevant)

타다 :)

네 가지 예는 다음과 같습니다.

GET /questions/123
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
POST (or PUT) /questions/123 q=What+is+the+meaning+of+life
GET /questions

질문을 추가하려면 :

POST /questions q=What+is+the+meaning+of+life

서버는 다음과 같이 응답합니다.

200 OK (or 201 Created)
Location: /questions/456