귀하의 언어 인 " 매우 낭비스러운 것 같습니다 ..."는 나에게 조기 최적화 시도를 나타냅니다. 객체의 전체 표현을 전송하는 것이 주요 성능 적중이라는 것을 알 수 없다면 (우리는> 150ms로 사용자에게 용납 할 수 없다고 말하고 있습니다) 새로운 비표준 API 동작을 만들려는 시도는 없습니다. API가 단순할수록 사용하기 쉬워집니다.
삭제는 서버가 삭제가 발생하기 전에 객체의 상태에 대해 알 필요가 없으므로 다음을 전송하십시오.
DELETE /emails
POSTDATA: [{id:1},{id:2}]
다음 생각은 응용 프로그램이 객체의 대량 업데이트와 관련하여 성능 문제가 발생하면 각 객체를 여러 객체로 나눌 때 고려해야 할 사항입니다. 그런 식으로 JSON 페이로드는 크기의 일부입니다.
예를 들어 두 개의 개별 전자 메일의 "읽기"및 "보관 된"상태를 업데이트하기 위해 응답을 보낼 때 다음을 보내야합니다.
PUT /emails
POSTDATA: [
{
id:1,
to:"someone@bratwurst.com",
from:"someguy@frommyville.com",
subject:"Try this recipe!",
text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1t Mustard Powder",
read:true,
archived:true,
importance:2,
labels:["Someone","Mustard"]
},
{
id:2,
to:"someone@bratwurst.com",
from:"someguy@frommyville.com",
subject:"Try this recipe (With Fix)",
text:"1LB Pork Sausage, 1 Onion, 1T Black Pepper, 1t Salt, 1T Mustard Powder, 1t Garlic Powder",
read:true,
archived:false,
importance:1,
labels:["Someone","Mustard"]
}
]
전자 메일의 가변 구성 요소 (읽기, 보관, 중요도, 레이블)를 다른 개체 (대상, 텍스트, 텍스트)가 업데이트되지 않으므로 별도의 개체로 분리합니다.
PUT /email-statuses
POSTDATA: [
{id:15,read:true,archived:true,importance:2,labels:["Someone","Mustard"]},
{id:27,read:true,archived:false,importance:1,labels:["Someone","Mustard"]}
]
또 다른 접근 방식은 PATCH를 사용하는 것입니다. 업데이트하려는 속성과 다른 모든 속성을 무시해야 함을 명시 적으로 나타냅니다.
PATCH /emails
POSTDATA: [
{
id:1,
read:true,
archived:true
},
{
id:2,
read:true,
archived:false
}
]
사람들은 조치 (CRUD), 경로 (URL) 및 값 변경을 포함하는 변경 배열을 제공하여 PATCH를 구현해야한다고 말합니다. 이는 표준 구현으로 간주 될 수 있지만 REST API 전체를 살펴보면 직관적이지 않은 일회성입니다. 또한 위의 구현은 GitHub가 PATCH를 구현 한 방법 입니다.
요약하면 배치 작업으로 RESTful 원칙을 준수하면서도 여전히 수용 가능한 성능을 유지할 수 있습니다.