Rest API : 자세한 표현을 통해 관련 리소스를 만드는 것이 합리적입니까?

Question

우리는 여러 가지 수집 자원을 가지고 있습니다. 그 다음에 동의 RESTfully하게 합리적인 것, 그러나

POST /people 
{ 
    "_links" : { 
     "car" : { 
      "href" : "/cars/66H8800" 
     } 
    } 
    "name": "John" 
} 

:

나는이 컬렉션 인스턴스 리소스를 만들 수 있습니까? /cars/66G8800가 존재하지 않은 경우

POST /people 
{ 
    "_links" : { 
     "car" : { 
      "license" : "66H8800" 
     } 
    } 
    "name": "John" 
} 

..., 자원 /people/1 (예를 들어), 그리고 /cars/66G8800의 생성을 초래할 것이다?

POST (새 리소스 생성)과 PUT (특정 리소스 업데이트/생성)의 목적이 혼합 된 것 같습니다.

Answer 1

요약 : 어느 쪽이든 괜찮습니다. # 1은 적어도 두 가지, 가능한 세 가지 요청에서주의해야합니다. 하나는 자동차를 PUT하고 다른 하나는 소유자/운전자를 POST합니다. 자동차에 대한 전체 리소스 데이터가 사전에 없으면 PUT 전에 해당 리소스에 대한 GET을 수행하고 필요에 따라 PUT 요청 본문을 업데이트하십시오. GET이 404를 반환하면 PUT에 알 수없는 필드를 비워두고 서버가 PUT 요청을 거부하는 대신 기본값으로 채우도록 정의합니다.

긴 대답 :

REST는 메시지 본문의 형식이 있어야 할 것을 지시하지 않습니다.

1. 균일 인터페이스,이 경우, HTTP의 POST 방법 :
   유일한 제약 REST는 당신이시 발생시킨다. POST를 사용한다는 것은 요청 본문에 정의 된 새 리소스를 대상 URI로 식별되는 컬렉션에 추가하려는 것입니다. 그렇게하면 서버가 다른 곳에서 리소스를 만들어야한다는 것을 요구하면 그렇게됩니다.
2. 문서화 된 미디어 유형이 선호됩니다. 기존 미디어 유형 (예 : application/hal+json)을 사용하거나 생성 한 미디어 유형을 문서화하십시오.
3. 하이퍼 미디어 (링크)를 사용하여 애플리케이션 상태 (브라우저 창)를 향상시킵니다. 요청 본문에서 원하는대로 보낼 수 있습니다. 자동차와 사람 사이에 하이퍼 링크를 제공하는 것은 서버의 책임입니다.
4. 요청은 자체 포함되어야합니다. 즉, "현재 차량을 66H8800으로 설정"하고 두 번째 요청으로 "현재 설정된 차량의 드라이버를 만들"요청을 보낼 수는 없습니다. 이렇게하면 서버 상태를 REST에서 금지 된 요청 사이에 기억해야합니다 (로드 균형 조정과 같은 여러 가지 문제가 발생 함). 이 일을하지 않는 것 같지만 제공된 코드를 통해 알 수는 없습니다.

"라이센스"키의 존재 여부를 나타내는 미디어 유형입니다. 보기에 적합하게 선택하거나 작성하십시오.