REST 표준을 의도적으로 위반하는 아키텍처 변경을 설명하는 방법은 무엇입니까?

여러 가지 문제로 어려움을 겪고있는 잘못 설계 한 소프트웨어 프로젝트에 대한 변경을 제안하고 있습니다. 높은 수준에서 프로젝트는 프론트 엔드에서 Angular를 사용하고 다양한 REST API를 소비합니다. 그것은 모두 훌륭합니다 (우리의 기술이나 도구를 변경할 필요가 없습니다). 문제는 코드 기반이 서버 측 API보다 UI에서 불균형 적으로 크다는 것입니다. 대부분의 비즈니스 로직은 UI에 있으며 REST API는 UI 계층에 대한 간단한 CRUD 데이터베이스 인터페이스입니다.

예를 들어 POST to customer는 고객 레코드를 생성하고 PUT은 해당 고객을 수정합니다. 더 많지 않고 훨씬 적습니다. 그러나 우리의 비즈니스 로직은 그보다 더 까다 롭습니다. 고객을 작성하는 일반적인 프로세스는 1 개의 데이터베이스 레코드를 삽입하는 것 이상을 수행합니다. 다른 필요한 테이블에 데이터를 프로비저닝하고 특정 유효성 검사 및 계산 등을 수행합니다.이 동작을 모두 캡슐화하여 소비 클라이언트의 부하를 줄이는 단일 POST / PUT 호출을 선호합니다.

따라서 제 관점은이 중요한 오케스트레이션이 UI가 아니라 서버 (모든 권한, 로그 등을 가진 서버)에 있어야한다는 것이지만, 한 가지 반론은이 접근법이 더 이상 RESTful하지 않을 것이라는 것입니다. 따라서 기존 기술 스택을 계속 사용하는 것이 좋지만 코드가 속한 위치에서 근본적인 변화를 구현할 때이 방법을 가장 잘 설명하는 방법을 모르겠습니다.

기존 기술 스택을 계속 사용하는 것이 좋지만 코드가 속한 위치에서 근본적인 변화를 구현할 때이 방법을 가장 잘 설명하는 방법을 잘 모르겠습니다.

Service oriented architecture.

비즈니스 규칙과 데이터가 같은 위치에 있도록 시스템을 재 설계 할 것을 제안하고 있습니다. 그것은 효과적으로 서비스 의 정의입니다 . 서비스 경계 찾기 에 대한 Udi Dahan의 대화를 참조하십시오 .

사이드 바 : Eric이 지적한 바와 같이, 이것은 "REST"와 관련이 없습니다. 서비스 앞에 REST API (즉, REST 아키텍처 스타일 의 제한 조건을 만족시키는 API)를 넣을 수없는 이유는 없습니다 . 그러나 REST를 이해하는 사람들은 데이터베이스 조작을 HTTP 메소드에 맵핑하는 것을 의미하지 않을 수 있습니다.

REST에 대한 독자의 이해를 바꾸는 데 투자 할 가치가 있거나 없을 수도 있습니다.

REST는 CRUD가 아닙니다. "반대론"은 REST가 무엇인지에 대한 근본적으로 결함이있는 이해를 바탕으로합니다. 귀하의 게시물에서 변경 사항으로 인해 API가 다소 RESTful하게된다는 것을 나타내는 아무것도 보지 못했습니다.

명심해야 할 또 하나의 사항은 다음과 같습니다. 비즈니스 규칙 서버 측을 검증하지 않으면 POST 요청을 통해 들어오는 모든 것이 유효하다는 것을 암시 적으로 신뢰한다는 의미입니다.

예를 들어, 앵귤러 애플리케이션은 고객이 유효한 연령대를 가지고 있는지 확인하고 합법적 인 사용자가 올바른 피드백을받을 수 있도록 보장하지만 API에 대한 URL을 아는 사람은 누구나 합법적이지 않은 일부 값을 포함하는 POST 요청을 수행 할 수 있습니다. 더 이상 검증되지 않습니다.

따라서 비즈니스 규칙을 API로 옮기고 입력을 확인하고 응답 본문에 적절한 오류 (또는 잘못된 것을 나타내는 코드)를 반환하도록 제안합니다. 이러한 코드는 프런트 엔드 응용 프로그램에서 문제를 나타내는 데 사용할 수 있습니다.

다른 좋은 답변을 추가하려면 다음을 수행하십시오.

구현 세부 사항에 대한 몇 가지 가정에 따라 REST 또는 기타 인터페이스를 제한해서는 안됩니다. 이것은 추상화 계층으로서의 서비스 개념과는 완전히 반대입니다.

서비스 사용의 주요 이점 중 하나는 클라이언트가 아무 것도하지 않아도 구현 세부 사항을 변경할 수 있다는 것입니다. 당신이 묘사 한 것에서, 그것은 실제 추상화 레이어가없는 것처럼 들립니다. 구현의 세부 사항은 HTTP를 통해 공개되었습니다. REST에 대해서는 그것이 필요하거나 도움이되거나 바람직하지 않다고 말합니다. 실제로 REST 정의 의 특정 부분 이 이것이 실제로는 비 RESTT 구현임을 의미 한다고 주장 할 수 있다고 생각 합니다.

당신이 제안하는 것은 적절한 서비스 계층이 어떻게 설계되어야 하는가입니다. 휴식이 아니기 때문에 할 수 없다고 누군가에게 말하면 불행한 일입니다. REST에 대해 거의 아는 사람이 없다는 것을 확신 할 수 있습니다.

귀하의 질문에 따라 customer라는 리소스가 있습니다. 유효한 고객 리소스를 생성하는 데 필요한 모든 것과 모든 것을 POST고객 기반 리소스 (또는 특정 고객 리소스에 대한 PUT에서 또는 선택적으로 PUT에서 존재하지 않는 경우) 에서 처리 할 수 ​​있고 처리해야 합니다. 특정 통화에서 생성해야하는 데이터베이스 레코드. Colin Young이 언급했듯이 데이터베이스가 전혀 필요하지 않으며 REST 관점에서 서비스가 구현되는 방식과는 전혀 관련이 없습니다.

여기에 좋은 답변이 있지만 동료들이 당신을 설득하는 데 도움이 될지 확실하지 않습니다. 많은 사람들이 지적했듯이, 제안하는 것은 RESTful 디자인에서 벗어나지 않는 것이지, 이것이 제안에 부응하는 것이 중요하다고 생각합니다.

REST는 API가 데이터 저장 및 검색 만 허용하도록하는 것이 아닙니다 . 오히려, 그것은 행동 모델링과 관련되어 같은 자원을. API 는 조치를 취할 수 있어야합니다 (결국 애플리케이션 프로그래밍 인터페이스 임). 문제는 이러한 조치를 모델링하는 방법 입니다.

용어를 사용하는 대신 예제가 동료에게이를 설명하는 가장 좋은 방법 일 것입니다 . 이렇게하면 현재 수행중인 작업, 이로 인해 발생하는 문제, 문제를 해결하는 솔루션 및 여전히 RESTful 상태를 유지할 수 있습니다.

고객 객체를 봅시다.

문제:

UI는 고객을 POST하지만 후속 테이블은 아직 업데이트되지 않았습니다. UI 코드 오류 (또는 브라우저 플러그인 오작동 등)로 인해 후속 호출 중 하나가 실패하면 어떻게됩니까? 이제 데이터가 일관성이없는 상태입니다. API 또는 UI의 다른 부분을 손상시키는 상태 일 수도 있으며 단순히 유효하지 않은 것은 말할 것도 없습니다. 어떻게 회복합니까? 이것이 가능한지 확인하기 위해 가능한 모든 상태를 테스트해야하지만 가능한 것이 무엇인지 아는 것은 어려울 것입니다.

해결책:

API 엔드 포인트를 작성하여 고객을 작성하십시오. create는 동사이며 REST를 위반하기 때문에 "/ customer / create"또는 "/ create-customer"엔드 포인트를 원하지 않는다는 것을 알고 있습니다. 그래서 그것을 명사. "/ 고객 생성"이 작동 할 수 있습니다. 이제 CustomerCreation 객체를 POST하면 고객이 완전히 생성되는 데 필요한 모든 필드가 전송됩니다. 엔드 포인트는 데이터가 완전하고 유효한지 (유효성 검사에 실패한 경우 400 또는 그 이상을 반환 함) 확인하고 단일 db 트랜잭션 내에서 모두 지속될 수 있습니다.

GET / customer 객체에 대한 엔드 포인트도 필요하다면 괜찮습니다. 둘 다 가질 수 있습니다. 비결은 소비자의 요구를 충족시키는 엔드 포인트를 만드는 것입니다.

장점 :

1. 당신은 당신이 나쁜 상태로 끝나지 않을 것을 보장합니다
2. 요청 순서, 유효성 검사 문제 등을 "알지"않아도되는 경우 UI 개발자가 실제로 더 쉽습니다.
3. API에 익숙하지 않으므로 네트워크 요청의 대기 시간을 줄입니다.
4. 시나리오를 테스트하고 개념화하기가 더 쉽습니다 (UI에서 누락되거나 잘못된 데이터 조각이 요청에 분산되지 않고 일부는 실패 할 수 있음)
5. 비즈니스 로직을보다 잘 캡슐화 할 수 있습니다.
6. UI의 비즈니스 및 오케스트레이션 논리를 사용자가 수정할 수 있기 때문에 일반적으로 보안이 더 쉬워집니다.
7. 논리 중복을 줄일 가능성이 높습니다 (동일한 데이터에 액세스하는 2+ API보다 API 소비자가 2 명 이상일 가능성이 높습니다)
8. 여전히 100 % RESTful

단점 :

1. 백엔드 개발자에게는 잠재적으로 더 많은 작업이지만 장기적으로는 아닐 수도 있습니다.

사람들이이 패러다임을 이해하기 어려울 수 있으며 시도하지 않은 경우 그 패러다임에 대해 좋은 점이 있습니다. 자신의 코드에서 예제를 사용하여 그들이 볼 수 있기를 바랍니다.

내 경험은 팀의 개발자가이 전략을 구현하기 시작하자마자 거의 즉시 이점을 보았다는 것입니다.

추가 연구 :

ThoughtWorks의에서이 문서는 정말 날 실용적인 예제를 사용하여 개체 등의 작업을 모델링의 아이디어를 얻을 도움 : https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling

또한 CQRS와 Event Sourcing 을 읽고 이러한 종류의 문제에 정확하게 관심 을 기울이면서 (즉, 실제 지속성 논리와 API를 구분하는 것) 읽어보십시오. 동료가 어떻게 이런 종류의 내용을 읽을 수 있을지 모르겠지만 더 명확하게 설명해 줄 수 있습니다.