자원 콜렉션에 Atom을 사용할 때 REST API 버전 관리

Question

이 내용은 반복되어 논의되었으며, 지금까지 내가 어디까지 왔는지에 대한 광범위한 연구를 수행했지만 최종 장애물을 극복 할 수는 없다고 생각합니다. .

우리 응용 프로그램에 대한 사용자 정의 REST API를 설계하고 있으며 미디어 유형을 사용하여 버전을 사용하고자한다고 결정했습니다. application/vnd.mycompany.resource.v2 + xml. 나는이 모델의 프로와 사기범을 깨닫고 가장 유연하게 무게를다는 것 같습니다.

=== REQUEST ===> 
GET /workspaces/123/contacts?firstName=Neil&accessID=789264&timestamp=1317611 HTTP/1.1 
Accept: application/vnd.mycompany.contact-v2+xml 

<== RESPONSE === 
HTTP/1.1 200 OK 
Content-Type: application/vnd.mycompany.contact-v2+xml 
<contact> 
    <name>Neil Armstrong</name> 
    <mobile>+61456838435</mobile> 
    <email>neil.armstrong@space.com</email> 
</contact> 

문제는 내가 아톰 내 자원 콜렉션을 나타내는 피드 져야 할 엔트리 사용하고자하는 것입니다 다음과 같이

따라서 내 GET이 보일 것이다. 이렇게하면 내 리소스 나 API 구조에 감염되지 않고 Atom의 검색과 페이지 매김을 활용할 수 있습니다. 자원의 내 컬렉션을 대표하는 아톰을 사용하여

=== REQUEST ===> 
GET /workspaces/123/contacts HTTP/1.1 
Accept: application/atom+xml; type=feed; 

<== RESPONSE === 
HTTP/1.1 200 OK 
Content-Type: application/atom+xml; type=feed; 
<feed xmlns="http://www.w3.org/2005/Atom"> 
    <title>Contacts Feed</title> 
    <link rel="self" href="https://api.mycompany.com/workspaces/contacts"/> 
    <updated>2011-11-13T18:30:02Z</updated> 
    ... 
    <entry> 
     <title>Neil Armstrong</title> 
     ... 
     <content type="application/vnd.mycompany.contact-v2+xml"> 
      <contact> 
       <name>Neil Armstrong</name> 
       <mobile>+61456838435</mobile> 
       <email>neil.armstrong@space.com</email> 
      </contact> 
     </content> 
    </entry> 
</feed> 

, 나는 미디어 유형을 사용하여 버전으로 능력을 상실 : 내 요청에 아톰을 사용하는 경우

는 내 요청 구조는 지금처럼 보인다. 미디어 유형이 이제 Atom 항목의 내용에 숨겨 짐에 따라

 <content type="application/vnd.mycompany.contact-v2+xml"> 

여전히 자원 수집 관리를위한 아톰의 힘을 사용하는 동안, 내 자원의 미디어 타입 버전을 결정하는 가장 좋은 방법은 무엇입니까?

내 생각에 ACCEPT 헤더를 통해 전달할 수 있습니다.

Accept: application/atom+xml; type=feed; version=1.0 

하지만 Atom 피드의 버전 1.0을 요구하고로 다음이 혼란은없는 자원 자체가 ...

은 어떤 도움이 정말 감사하겠습니다!

Answer 1

문제는 IMHO가 미디어 유형을 잘못 사용하고 있다는 것입니다.

미디어 유형은 실제 페이로드의 구조에는 정보를 제공하지만 페이로드의 SEMANTICS에는 정보를 제공하지 않습니다. "이것이 XHTML 페이지라는 것을 알고 있지만 블로그 게시물인지 또는 Amazon의 항목인지는 알 수 없습니다." XHTML 페이지가되면 페이로드에서 구성 요소를 가져 와서 재미있는 질문을하는 방법을 알지만 페이로드 해석은 미디어 유형의 일부가 아닙니다.

Roy Fielding의 예를 바꾸어서 10,000 비트 배열을 100x100 픽셀의 GIF 파일로 보내는 예를 생각해보십시오. "모두가 알고있는"GIF는 사진을 보내는 데 사용되지만 실제로는 더 간단합니다. 이것은 대부분의 경우 이미지로 나타나는 구조화 된 바이너리를 전송하는 메커니즘입니다. 따라서 10,000 비트 배열 (아마도 00과 FF의 그레이 스케일 이미지로 표현됨)을 전송하는 데이 경우, 일반 디코더 (GIF), 압축시 내장 된 GIF 등의 이점을 얻을 수 있습니다.

하지만이 경우 그림이 아닙니다. 사진으로 보여줄 수는 있지만 의미없는 그림입니다. 이 경우 그림 시나리오에 사용되는 고전적인 의미가 없습니다. 이점은 형식의 편재성입니다.

또 다른 예는 수년 전 엔지니어가 레이더 연구를하고 있었던 때였습니다. 따라서 책과 같은 책에서 발견 할 수있는 항공기의 3면 도면을 찍어서 AutoCAD 도면에 타블렛으로 인코딩 할 것입니다. DWG 형식은 잘 문서화되어 있었고 코드를 읽을 수있는 코드가있었습니다.그가 원했던 것은 특정 항공기의 좌표와 측정 값이었습니다.

그래서 결국 "의미가 없다"는 내용의 줄이있는 "의미없는"AutoCAD 파일이 여러 개 있습니다. 그러나 사실 그들은 자신의 도메인에 대한 좋은 정보로 가득 차있었습니다. DWG 파일은 미디어 유형 이었지만 이것들은 "CAD 도면"이 아니 었습니다. (자발적 재사용이라고 할 수 있습니까?)

미디어 유형을 통해 무언가를 버전화하는 것이 좋지만, 사실 미디어 유형이 실제로 변경되는 경우에만 관련이 있습니다. 귀하가 언급 한 바와 같이 ATOM은 변경되지 않거나 적어도 귀하의 통제하에 변경되지 않으며, 변경 될 경우 새로운 버전을 지원하지 않을 수도 있습니다. 그러나 ATOM은 정보가 어떻게 표현되고, 정보가 어떻게 인코딩되며, 변하지 않기 때문에 변하지 않습니다. 정보가 잘 변할 수 있으며 실제로는 항상 바뀝니다. 모든 ATOM 피드는 정보가 다르면 다릅니다. 대부분의 경우 비슷한 의미 (블로그 피드)를 사용하지만 대부분은 그렇지 않습니다 (예 : 시나리오).

하지만 ATOM 피드를 구문 분석하고 정보를 가져 오는 방법은 변경되지 않습니다. 그리고 그것이 바로 미디어 유형입니다. 정보 그 자체가 아니라 정보의 부호화.

따라서 버전 관리를 검색하려면 페이로드를 확인하십시오. 그것을 검사하십시오. 예를 들어 송장 번호가 (예 : XPATH의 invoice/inv_no에있는) V1과 같은 데이터의 V1에 대해 알 수 있습니다. 송장이 거기에 없다면, 당신은 무엇을합니까? 당신은 a) 다른 잘 알려진 장소 (즉, V2)를 보거나, b) 오류를 던집니다 ("이게 뭐든간에, 송장이 아닙니다!"). 버전에 관계없이 또는 미디어 유형이 무엇이든 또는 다른 어떤 내용이 무엇이든 관계없이 무엇이든 얻을 수 있기 때문에 무엇을 하든지 상관없이 그렇게해야합니다.

페이로드가 호환 가능하도록 이전 버전과 호환되도록 설정할 수 있습니다. 그런 다음 버전 정보는 사용자가 볼 수있는 모든 정보를 사용하는 문제입니다. A와 B를 얻는다면, C와 D도 갖고 싶어하지만, 고객은보다 제한된 정보로 얻을 수 있습니다. 클라이언트가 C와 D를 보는 경우, A와 B는 해당 데이터가 사용되지 않으므로 무시한다는 것을 알게됩니다. 서버와 동일합니다. 어떤 것이 A와 B를 보내는 중이라면 C와 D를 함께 보낸 것보다 오래된 처리 모델이라는 것을 암시합니다.

rel 이름 "order"vs "order_2"를 통해 버전을 올릴 수 있습니다. 예전 클라이언트는 " 새로운 고객은 "order_2"를 사용하고 대신 해당 링크를 따라야한다는 것을 알고 있습니다.

또는 단순히 페이로드에 버전 식별자를 포함하면 쉽게 확인할 수 있습니다 (특히 디자인 초기이기 때문에).

버전 관리에는 많은 방법이 있지만 미디어 유형이 실제로 메커니즘이되어서는 안됩니다. 그래서 이것이 정말로 ATOM의 "문제"가 아닙니다. 그래서, 그것은 원근법의 문제입니다.

나는 여기 수락 헤더에 대한 또 다른 설명이 있습니다 REST API having same object, but light

이 (IMHO) 당신의 버전 문제와 관련이없는,하지만 그것은 확장 된 미디어 유형의 예입니다. 그러나 그것은 왜 대부분의 사람들이 "버전 관리"를 원하는지에 대한 나의 인식입니다. 이 경우는 동일한 경우가 될 수 있지만 대부분의 사람들은이 다른 게시물이 주로 사용한 데이터 표현이 아닌 서비스와 버전 관리를 연관시킵니다.

결국 클라이언트 및/또는 서버는 버전이있는 데이터를 처리 할 수있을 정도로 유연하거나 그렇지 않습니다. 그들은 (결국, 그들은 결국 컴퓨터입니다. 결정론적인 나의 허니 ...) 그들이 말한 것을하십시오. "알지 못하는 내용을 무시하는"간단한 규칙은 인코딩에 관계없이 v1을 v2로 변경하지 않고 버전 관리 측면에서 상당히 멀리 할 수 ​​있습니다. 마찬가지로 "가지고있는 것과 함께 작업"은 유연하고 관대 한 서버에 대한 좋은 규칙입니다.어느 경우 든 문제가 발생하면 오류, 로그, 운영자 및 24 시간 호출기가 필요하므로 어쨌든 필요합니다.