0
100 개 이상의 테이블이있는 관계형 데이터베이스가 있다고 가정 해보십시오. 각 테이블은 엔티티 (사람, 주소, 차량, 개 등)의 일종을 모델링합니다. 나는이 데이터베이스에 데이터를 POST하기를 원하는 사람들과 편안한 API를 가지고있다. 여러 번이 데이터는 웹 양식 또는 그와 유사한 것으로부터 XML 패키지 또는 POST 데이터로 제공됩니다. 때로는 데이터베이스의 모든 테이블 (때로는 대부분의 테이블)에 게시해야하는 경우가 있습니다. 안정적인 리소스 및 관계형 데이터베이스가 호환되지 않습니다
이제
POST /person
POST /email
POST /vehicle
POST /insurance
의 편안한 방법을 통해 100 개 이상의 테이블 지속성에 멀티 리소스 데이터의 덩어리를 게시 할 우리의 고객 요구
미친 짓이야! 그래서 우리는POST /auto-record
{ post body of key values for all the tables needed to make an 'auto-record' }
이며이 필요한 데이터베이스의 여러 테이블에 삽입을 할 줄 아는 비즈니스 로직의 일종에 연결된다 대신 자원을 가질 수 있습니다. 좋아. 그러나 이제는 그것에 대해 생각하고 있습니다.이 디자인은 개방형/폐쇄 형 원칙을 준수합니까? 우리가 업데이트/추가/제거해야할 필요가있는 경우 '자동 기록'은 고객을 망쳐 놨습니다.
api는 리소스 그룹화를 어떻게하면 편안하게 처리 할 수 있습니까? 아니면 간단하지 않습니까? 대안이 있습니까?
당신은이 질문에 대해 의견을 바탕으로 한 영역으로 들어서고 있습니다. 누가 모든 프로그램이 모든 고체 원칙을 따라야한다고 말했습니까? 종종 다른 이익의 이름으로 당신은 당신이 평소 따라야 할 몇몇 교장을 포기합니다. –
나는 귀하의 접근 방식에서 RESTful 패턴 위반에 대해 알지 못합니다. 아마도'auto-record'가 너무 추상적이기 때문에 리소스 이름의 이름을 바꾸는 것을 고려해야 할 것입니다. GET, POST, UPDATE 또는 DELETEs보다 복잡한 엔티티 (자신의 애완 동물, 주소 등의 목록을 가진 사람)가 제공하는 리소스를 제공하면 아무런 문제가 없어야합니다. 아래 내 대답을 참조하십시오. P.S. : REST 원칙은 교리가 아니며 리소스로 작업하기 위해 HTTP 프로토콜을 올바르게 사용하는 것입니다. – klimpond