헤더 값: application/vnd.api+json

헤더 값: application/vnd.api+json

다음 간의 차이점을 설명해 주시겠습니까?

application/vnd.api+json

그리고.

application/json

미디어 타입application/vnd.api+json는 JSON API를 나타냅니다.자세한 내용은 이쪽에서 보실 수 있습니다.

즉, JSON API는 독단적이고 합리적인 것입니다.

…리소스의 Import 또는 변경을 클라이언트에 요구하는 방법 및 서버가 이러한 요구에 응답하는 방법에 대한 사양.

벤더 접두사(vnd.)는 이 벤더의 사용자 지정임을 나타냅니다.+json은 JSON으로 해석할 수 있음을 나타내지만 미디어 유형은 JSON 위에 추가 의미를 정의해야 합니다.

첫 번째는 API 고유의 미디어 유형입니다.벤더 프리픽스(vnd.)는 이 벤더의 커스텀임을 나타냅니다.그+json는 JSON으로 해석할 수 있음을 나타내지만 미디어 타입은 JSON 위에 추가 시멘틱스를 정의해야 합니다.

두 번째는 내용이 JSON임을 의미합니다.다만, 이것은 JSON 값의 의미를 정의하지 않기 때문에, 일반적으로는 그다지 유용하지 않습니다.

이에 대한 자세한 내용은 Wikipedia에서 참조하는 것이 좋습니다.다만, 그 페이지의 대응하는 RFC의 링크를 참조해 주세요.

확실하지 않은 경우 다음을 사용하십시오.application/json-- 올바른 형식의 JSON이 되기 위해 반환되는 데이터만 필요한 일반 MIME 유형입니다.

---

그application/vnd.api+jsonMIME 유형은 (혼합된 이름의) "JSON API" 프로토콜을 사용한 통신용으로 예약되어 있습니다.

이 컨텍스트에서 "JSON API"는 HTTP 및 JSON에 기반한 API를 의미하지 않습니다.완전히 지정된 API도 아니고 클라이언트가 상호 관련 엔티티를 가져오고 수정할 수 있는 API를 구축하기 위한 프레임워크입니다.예를 들어, 블로그 애플리케이션은 "JSON API" 사양에 부합하는 API를 구현할 수 있습니다. 이 API는 특정 작성자가 작성한 마지막 10개의 기사를 각 기사에 대한 메타데이터 및 코멘트와 함께 하나의 HTTP 요청으로 가져올 수 있습니다.

이 사양은 특히 다음을 정의합니다.

• 요청이 형성되어야 하는 구체적인 방법(즉, 정렬과 페이지 매김을 제어하는 URL 파라미터와 출력에 포함된 데이터)
• 응답에 포함된 JSON 문서의 특정 구조. 예를 들어 다음과 같습니다.

문서에는 다음 최상위 구성원 중 하나 이상이 포함되어야 합니다.

• data의 ' 데이터 : '프라이머리 데이터'
• errors 오브젝트 : " " " " "
• meta: 비표준 메타정보가 포함된 메타오브젝트

는 ★★★★★★★★★★★★★★★★.data ★★★★★★★★★★★★★★★★★」errors같은 문서에 공존해서는 안 됩니다.

MIME(Multipurpose Internet Mail Extensions) 유형(또는) 미디어 유형은 인터넷을 통해 전송되는 문서의 특성 및 형식을 나타내는 표준화된 방법입니다.IETF RFC 6838에 표준화되어 있습니다.IANA(Internet Assigned Numbers Authority)는 모든 공식 MIME 유형을 추적하는 공식 기관입니다.

JSON API에서 사용되는 미디어 유형은 application/vnd.api+json이며 IANA에 올바르게 등록되어 있습니다.

API+JSON 미디어 타입은 JSON을 제공하는 다른 API 간의 상호 운용성을 위한 것입니다.

"thick JavaScript" 클라이언트와 그 요구를 고려하여 작성되었지만 특정 클라이언트에는 없습니다.그래서 앞에 가 붙는다.vnd( ( )

JSON API에서 몇 가지 포인트 추가:

• JSON API는 요청 및 응답 방법에 대한 API 사양을 정의하는 규격입니다.
• 잘 정의된 구조(리소스 - 관계 및 링크 등)를 만들 수 있습니다.
• CRUD 동작에 대해 REST API가 반응하는 방법을 지정합니다.
• 클라이언트가 응답을 캐시할 수 있습니다.

이것을 MIME 타입의 버전 설정 또는 컨텐츠의 네고시에이션이라고 부릅니다.REST API를 개발할 때 나중에 해당 API의 다른 버전(예를 들어 v1, v2 등)을 추가할 수 있으며, API의 다른 사용자가 원하는 버전을 호출할 수 있어야 합니다.URI Versioning, Parameter Vesioning, Header Versioning, MIME Versioning 등 이 API의 버전화 문제를 해결하기 위한 다양한 접근법이 있습니다.

예를 들어 MIME Versioning에 대해 설명하겠습니다.

REST API가 다음과 같이 응답하는 Person 엔티티가 있다고 가정합니다.

public class Person {

   private String name;
   private String email;

   public Person() {
   }

   public Person(String name, String email) {
       this.name = name;
       this.email = email;
   }

   public String getName() {
       return name;
   }

   public void setName(String name) {
       this.name = name;
   }

   public String getEmail() {
       return email;
   }

   public void setEmail(String email) {
       this.email = email;
   }

}

그러나 우리가 원하는 것은 API의 호출자가 버전을 언급하고 그에 따라 적절한 담당자와 함께 응답하는 것입니다.Rest Controller는 다음과 같습니다.

@RestController
public class PersonController {
    
    @GetMapping(path = "/person", produces = "application/vnd.company.api-v1+json")
    public Person getPersonV1() {
        return new Person("Mr. ABC", "abc@gmail.com");
    }

    @GetMapping(path = "/person", produces = "application/vnd.company.api-v2+json")
    public Person getPersonV2() {
        return new Person("Mr. XYZ", "xyz@gmail.com");
    }
}

이제 다른 버전의 API를 검색하여 API로부터 적절한 답변을 받습니다.아래 출력을 확인하십시오.

application/vnd.company.api-v1+json 버전 1을 요구하고 있습니다.

application/vnd.company.api-v2+json 버전 2의 요구

이 MIME 버전 관리 방식을 사용하여 REST API 버전을 만드는 방법을 확인할 수 있습니다.API 버전 관리에는 조직마다 다른 접근 방식을 사용합니다.

언급URL : https://stackoverflow.com/questions/28055526/header-value-application-vnd-apijson