다양한 도메인 개체에 대해 CRUD 작업을 제공하는 RESTFul 서비스를 디자인하고 있습니다. 이러한 객체 중 하나가 Person입니다.URL 매개 변수가있는 HTTP POST - 서버는 무엇으로 응답해야합니까?
우리는 다음과 같은 서비스가 있습니다
GET /person/list?type=Infant
POST /person/list
은 페이로드에있는 사람 목록을 허용하고 그러한 레코드를 만듭니다.
질문 : 는 어떤 경우에, 우리는 페이로드에 전달 된 사람을 만들 것입니다 다음 유형의 유아의 모든 사람의 목록으로 응답
POST /person/list?type=Infant
에 대한 의미가 있습니까?
가장 좋은 방법은 무엇입니까?
본인은 "페이로드에 전달 된 사람을 만든 다음 유아 유형의 모든 사람의 목록으로 응답하십시오."라는 말에 만족하지 않습니다. 두 가지 작업은 별도로 수행해야합니다.
/person/list가 사람을 추가하기위한 api가되는 것이 당연하다고 생각하지 않습니다. 어떤 것이 든/person/add 여야합니다. 영리하려고 노력하는 것을 금지하는 REST에 대한 구체적인 것은 없지만,/person/add에 대한 응답은 추가 결과 일 것입니다. 몇 가지 추가 기능을 접목하려고하면 클라이언트 (예 : API를 사용할 사용자)가 더욱 복잡해집니다.
/person/list에 게시하면 새 사용자를 추가 할 때 아무런 문제가 없습니다. 그것은 매우 일반적인 관습입니다. –
나는 그것에 문제가 있다고 말하지 않았다. 그러나, 나는 그 접근법에 어떤 가치도 보이지 않으며, REST는 그 관습을 사용하도록 확실히 명하지 않는다. 예를 들어, 오랫동안 사용해온 Flickr는 http://api.flickr.com/services/upload/에서 사진을 업로드 할 때이를 사용합니다. 네가 할 수 있다고해서 네가해야한다는 뜻은 아니다. – gview
동사가있는 URI를 사용할 때의 문제점은 요청의 의미가 무엇인지 항상 명확하지 않다는 것입니다. 예를 들어, GET/person/add는 무엇을합니까? –
감사합니다. 정교하게 신경 써야합니까? Atom Pub뿐만 아니라 HTTP spec을 읽으려고합니다. 나는 이것을 명시 적으로 금지하는 곳을 찾을 수 없었다. 이 접근법을 따르면 어떤 문제가 발생할 수 있습니까? – Sam
문제가 발생하지는 않지만 일반적으로 클라이언트는 서버가 처리하고 적절한 응답을 반환하는 요청을 시작합니다. 'POST/persons'의 경우, 새로운 엔트리 (person)가 생성되어야합니다. 이 경우 임상가의 요청에 리소스 이름이 지정되어 있지 않으면 새 개체 URL 경로가 반환됩니다. 새 항목의 ID는 서버에서 작성되며 대개이 POST 작업에 대한 응답으로 반환됩니다. POST는/etc/resources/resources 아래에있는 자원을 만듭니다. 예를 들어,/persons/sam –