게시 데이터에 대한 REST 표준

타다가 게시되고 모델은 엠버가 "user" 객체로 데이터를 포장했다

{ 
    "user": { 
     "firstName": "Vivek", 
     "lastName": "Muthal" 
    } 
}

입니다.
그러나 서면으로 작성한 서비스는 {"firstName":"string","lastName":"string"}만을 허용합니다.

제 질문은 REST 표준이 랩된 객체에서만 데이터를 보내고 받도록 지정합니까?
아무런 언급이 없으므로 서비스를 적절하게 변경할 수 있습니다.
그렇지 않으면 현재 서비스를 그대로 사용하도록 수정합니다. 감사.

출처

2014-06-17 Vivek Muthal

리소스가 User 인 것으로 가정하므로 JSON은 User을 나타내야합니다. 이 URI 스키마가 있다고 가정 해 보겠습니다. 우리가 GET을 수행 할 때

GET /host/users/{userId} 
PUT /host/users/{userId} 
POST /host/users

는 우리가 기대 표현하는 JSONUser

{ 
    "firstName": "Vivek", 
    "lastName": "Muthal" 
}

우리는 이미 POST에 대한 우리의 GET 요청, 같은 언급하기 때문에 리소스 이름을 지정할 필요가 없습니다, 요청 본문에 리소스 이름을 언급 할 필요가 없습니다. 왜냐하면 요청이 URI에 지정되어 있기 때문입니다. 아무 것도 없기 때문에 user 키가 필요하지 않습니다.

출처

2014-06-17 11:17:08

맞아, GET/host/users 다음에 ember가 "users"객체에서 응답 배열을 원한다고 가정합시다. 나는 단지 그것을 확인하기 위해 더 많은 설명이나 참조를 원한다. 엠버가이 대회를 왜 강요하는지 이해하지 마십시오. –

@VivekMuthal Ember가이 규칙을 강제하는 이유는 알지 못합니다. REST에서 리소스를 식별하는 올바른 방법은 URI에 의한 것입니다. JSON은 URI로 식별되는 리소스를 나타냅니다. –

정보 주셔서 감사합니다. 엠버에서 발견 된 해결책. 그들은 단지 serializeIntoHash를 추가해야하는 RESTSerializer를 제공합니다 : function (hash, type, record, options) {Ember.merge (hash, this.serialize (record, options)); } –

REST는 uniform interface constraint을 정의합니다. 이 제약 조건은 표준 솔루션을 사용하여 서비스와 클라이언트 간의 일관된 인터페이스를 만들어야한다는 것을 의미합니다. 이 방법은 우리가 사용하는 표준이 서버에 의해 유지 관리되지 않기 때문에 서비스의 구현 세부 사항에 의해 클라이언트가 분리 될 것입니다 ...

간결하게하려면 모든 표준 MIME 유형을 사용하거나 특정 벤더를 정의하십시오 MIME 유형. JSON-LD + Hydra 또는 HAL과 같은 기존 하이퍼 미디어 형식을 사용하는 것이 좋습니다. 이런 종류의 직렬화는 엠버 특정 일이라고 생각합니다.

출처

2014-06-17 11:57:24 inf3rno

아니요. HTTP 요청 본문에 보내는 데이터에 대한 미리 정의 된 형식은 없습니다. 좋습니다. HTTP RFC는 보내는 데이터에 기술적 인 제한을 두지 만 형식은 전적으로 사용자에게 달려 있습니다.

이와 같이 원하는대로 데이터의 서식을 지정할 수 있습니다. 리소스를 나타 내기 만하면됩니다. 당신은 사용자를위한 JSON이 분명히 객체를 '사용자'로 표시해야하는지 아닌지 고려해야 할 필요가있다.

출처

2014-06-17 12:31:33 thecoshman

게시 데이터에 대한 REST 표준

답변

관련 문제