REST 응답에 meta data를 포함하는 것
![]() |
---|
rest 응답에 메타정보를 포함하는 방식 |
REST API 설계의 기본이라는 동영상을 보다보니, 데이터 이외에 메타정보를 포함하는 내용이 나온다.
REST를 구성하면서 한 번도 생각해 본적이 없는 것이라 살짝 당혹스럽다.
물론 차세대라고 불리는 SI 할 때는 응답전문에 복수의 배열이 포함될수 있음으로 배열명과 동일한 _변수를 반드시 선언하는 식으로 많이들 하긴 했었다만.
이것을 좀더 나이스한 메타정보로 어찌해 볼 생각은 왜 못했을까 싶다.
![]() |
---|
GET, POST의 용법에 대해서도 다시 생각한다 |
물론 기본은 기본이지만 나는 대부분 GET과 POST로 모든것을 다 처리하고 있었는데 말이다.
![]() |
---|
WSML수준의 API |
이 장면을 보면서 생각한다. 내가 생각하는 수준의 API구나. 즉, 옛날 사람 이구나.
PUT과 PATCH의 차이
The HTTP put and patch verbs are both used to update resources, but for HTTP, they have different behaviors.
- Put completely replaces a resource with the provided payload. put은 리소스를 제공된 페이로드로 완전히 바꿉니다.
- Patch should only be used to modify a subset of the resource. patch는 리소스의 하위 집합을 수정하는 데만 사용해야 합니다.
RFC 7396: JSON Merge Patch 설명 RFC 7396은 JSON 문서의 일부를 간단하게 수정할 수 있도록 설계된 JSON Merge Patch 포맷과 그 처리 규칙을 정의합니다. 이 포맷은 주로 HTTP PATCH 메소드와 함께 사용되어, 기존 JSON 리소스의 특정 부분만을 효율적으로 변경할 수 있게 해줍니다
동작 방식
- Merge Patch 문서는 실제로 변경하고자 하는 부분만 포함한 JSON 객체입니다.
- 서버는 이 Merge Patch를 기존 JSON 문서에 적용하여, 지정된 필드만 수정하거나 삭제합니다.
- 값이 null로 지정된 필드는 삭제됩니다.
- 객체가 아닌 값(예: 문자열, 숫자, 배열 등)이 패치로 오면, 전체 타겟 값이 해당 값으로 대체됩니다
특징 및 제한
- 간단함: 변경하고자 하는 필드만 명시하면 되고, 나머지는 그대로 유지됩니다.
- null 값: 필드에 null을 지정하면 해당 필드가 삭제됩니다.
- 배열 지원 제한: 배열 내 일부 요소만 부분적으로 수정하는 것은 지원하지 않습니다. 배열 전체를 대체하는 방식만 가능합니다. 더 복잡한 패치 기능이 필요하다면 RFC 6902(JSON Patch)를 사용해야 합니다.
- 텍스트 표현 보존 X: Merge Patch는 데이터 항목 수준에서 동작하며, JSON의 공백, 멤버 순서, 숫자 정밀도 등은 보장하지 않습니다