API를 조립할 때 액션을 엔티티 세트로 수행합니다. 내가 가지고있는 문제는 클라이언트의 환경 설정 및 지원되는 방법에 따라 동작을 다양하게하는 방법입니다.REST API 디자인 - 리소스 하위 유형 처리
일부 동작 유형에는 추가 옵션을 제공하기 위해 클라이언트가 필요할 수 있습니다. 예를 들어 동작 중 하나가 전자 메일을 보내 게되므로 클라이언트가 본문,받는 사람 등을 제공해야합니다. 서버는 클라이언트가 수행하는 것보다 많은 조치 유형을 알 수 있습니다. 예를 들어 새로운 전송 방법을 추가 할 수 있지만 이전 클라이언트는 옵션을 설정하는 방법을 알지 못합니다. 뿐만 아니라 클라이언트에서 옵션을 필요로하지 않는 작업 유형이 있으므로 모든 클라이언트가 서버에서 서버를 사용할 수있게되는 즉시 사용할 수 있습니다.
클라이언트/서버에서 지원하는 동작 유형을 기반으로 동작 유형을 변경하는 것뿐만 아니라 선택된 엔터티도 효과가 있습니다. 일부 엔터티는 일부 동작 유형에 유효하지 않습니다.
이 협상이 끝나면 클라이언트 (최종 사용자)는 해당 엔티티에 적용 할 수있는 '옵션 없음'작업 유형 또는 '필요 옵션'작업 유형 중 하나를 자유롭게 선택할 수 있습니다 이러한 엔터티에 적용 가능하며 클라이언트와 서버에서 모두 지원됩니다.
상태 필드를 committed 또는 이와 유사한 값으로 설정하면 작업이 트리거됩니다.
내 생각에 지금까지 일반적인 DoAction 리소스와 하위 개체 컬렉션을 제공하는 것이 좋습니다. 이 리소스의 속성을 사용하면 'ActionType'을 지정할 수 있습니다. ActionOptions이라는 또 다른 하위 리소스가 있으며 사용중인 특정 유형의 옵션을 설정하거나 '옵션 없음'유형의 경우 비워 둡니다.
이것이 가장 좋은 접근 방법인지 또는 콘텐츠 유형과 관련된 것이 더 좋을지 결정하는 것입니다. 또한 옵션 옵션을 포함하여 클라이언트의 사용 가능한 작업 유형 목록을 협상하는 방법도 있습니다. 클라이언트가 명시 적으로 알지 못하는 경우에도 클라이언트가 지원할 수있는 유형.