HTML 양식을 RESTful하게 보내는 방법은 무엇입니까?

Question

'facts'라는 리소스 모음에 대한 URI와 해당 컬렉션의 각 'fact'리소스에 대한 URI가 있습니다.

새로운 '사실'을 만들기위한 양식은 GET으로 요청해야한다고 생각합니다. 그러나 어떤 URI를 만들지 결정하는 데 문제가 있습니다.

컬렉션 URI에 대한 GET은 '사실'리소스 URI의 목록을 반환해야합니다. 각 '사실'URI는 GET에 대한 응답으로 그 내용을 반환해야합니다. 실제 '사실'생성은 당연히 상황에 따라 POST (또는 PUT) 일 것입니다.

나는 몇 가지 옵션을 볼 수 있지만, 어느 것도 만족스러운 보이지 않는다 :

1. 이 '사실'URI가 참조하는 '사실 양식'URI를 추가합니다. 이 URI에 대한 GET은 HTML 양식을 제공합니다. 리소스에 대한 설명을 위해 다른 리소스를 갖는 것이 잘못되었습니다.
2. 헤더에 양식 데이터를 포함하지 않고 '사실'URI에 대한 POST는 양식을 리턴합니다. 그런 다음 사용자가 양식을 채우면 양식 데이터로 POST하고 새로운 '사실'자원을 작성합니다. 이것은 더 나쁜 접근법처럼 보입니다.
3. 양식을 유선으로 보내지 않고 API의 일부로 포함 시키십시오. 이것은 REST API가 미디어 유형을 설명해야하고 RESTful 인 것처럼 보이며 '사실'유형에 대한 설명으로 양식을 작성할 수 있습니다. 이것은 구현하기가 이상합니다. 아마도 REST 서비스는 일반 웹 사이트와 별개이므로 실제 HTML 양식 요청은 REST API를 제외한 일부 URI에있다.
4. '사실'URI 응답의 일부로 HTML 양식을 포함하십시오.

명확히하기 위해, 저는 REST로 포즈를 취한 RPC가 아닌 Roy Fielding이 지정한 진정한 REST 아키텍처를 따르려고합니다.

편집 : # 3이 (가) 무언가에 있다고 생각하기 시작했습니다.

edit2 : 해결 방법은 일반적인 REST가 아닌 HTML 탐색을 CRUD 방식으로 수행 한 다음 프론트 엔드가 적절하게 AJAX REST 호출을 작성하거나 백엔드가 REST API에 내부 호출을 작성하는 것입니다.

이 서비스의 나머지 부분을 올바르게 수행해야하는 이유는 다른 비 HTML 클라이언트가 나중에이 서비스와 상호 작용할 수있게하려는 것입니다.

Answer 1

나는 당신이 약간 복잡해지고 있다고 생각합니다. 웹 브라우저는 완벽한 REST 클라이언트가 아니므로 완벽하게 RESTful 솔루션을 가질 수는 없습니다. 완벽한 세계에서는 웹 브라우저가 미디어 유형을 알고 양식 자체를 작성하기 때문에 양식이 전혀 필요하지 않습니다.

한편, 대부분의 REST 프레임 워크에서 리소스에 대한 추가 '보기'를 호출하여 양식을 반환하는 것이 좋습니다.
예 : /your/collectionresource?view=form, 또는 내 마음에서

Answer 2

/your/collectionresource;form, 유일한 깨끗하게 편안하고 답변은 내가 그것을보고, 자원의 설명은 자신의 자원 1과 3

있습니다. 문제는 애플리케이션의 API를 통해이 리소스에 액세스 할 수 있도록할지 또는 API의 일부로 사용할지 여부입니다.- GET > 모든 사실/사실/1 -> 사실 1 (분명히 ID가 단어 또는 뭔가 다른 수 있습니다를 반환

GET/사실 : 1의 경우

, 편안하고이 같은 URI에 뭔가를 만들 것) GET/facts/create -> 사실 만들기에 적합한 양식을 반환합니다. POST/facts -> 사실을 추가합니다.