REST API抽象資源屬性？

從消費者的角度來看，有沒有抽象的任何資源屬性值，使場自描述？或者文檔應該處理它。REST API抽象資源屬性？

的想法是，每一個屬性將被包裹在一個更復雜的對象，這將提供fieldId，字段類型，和的值。使每個領域更具描述性。

此外，Web服務將包括另一個端點進一步描述每個字段。

所以，相反的以下內容：

{ 
    "id":123, 
    "type":"person", 
    "attributes":{ 
     "name":"John Smith", 
     "dateOfBirth":"2000-01-01", 
     "ssn":123456789 
    } 
}

JSON的應該是這樣的：

{ 
    "id":123, 
    "type":"person", 
    "attributes":[ 
     { 
     "fieldId":"name", 
     "dataType":"string", 
     "value":"John Smith" 
     }, 
     { 
     "fieldId":"dateOfBirth", 
     "dataType":"date", 
     "value":"2000-01-01" 
     }, 
     { 
     "fieldId":"ssn", 
     "dataType":"integer", 
     "value":123456789 
     } 
    ], 
    "relationships":{ 
     "dataType":{ 
     "links":{ 
      "related":{ 
       "href":"http://acme.com/ws/dataTypes/" 
      } 
     }, 
     "data":[ 
      { 
       "id":"string", 
       "type":"dataType" 
      }, 
      { 
       "id":"date", 
       "type":"dataType" 
      }, 
      { 
       "id":"integer", 
       "type":"dataType" 
      } 
     ] 
     }, 
     "field":{ 
     "links":{ 
      "related":{ 
       "href":"http://acme.com/ws/fields/" 
      } 
     }, 
     "data":[ 
      { 
       "id":"name", 
       "type":"field" 
      }, 
      { 
       "id":"dateOfBirth", 
       "type":"field" 
      }, 
      { 
       "id":"ssn", 
       "type":"field" 
      } 
     ] 
     } 
    } 
}

再掛一個數據類型資源，將給予一定的說明和/或格式：

{ 
    "id":"ssn", 
    "type":"field", 
    "attributes":{ 
     "valueType":"string", 
     "description":"Social security in the xxx-xx-xxxx format." 
    }, 
    "links":{ 
     "self":{ 
     "href":"http://acme.com/ws/fields/ssn", 
     "meta":{ 
      "httpMethod":"GET" 
     } 
     } 
    } 
} 

{ 
    "id":"date", 
    "type":"dataType", 
    "attributes":{ 
     "valueType":"string", 
     "description":"yyyy-MM-dd" 
    }, 
    "links":{ 
     "self":{ 
     "href":"http://acme.com/ws/dataTypes/date", 
     "meta":{ 
      "httpMethod":"GET" 
     } 
     } 
    } 
}

來源

2015-11-19 user2793390

或者你選擇一個現有的格式：http://sookocheff.com/post/api /上選擇-A-超媒體格式/;） – sp00m

回答這個問題From the perspective of a consumer, is there any value in abstracting resource attributes to make the fields self-describing? Or should the documentation handle it.

基於經驗和評估多個API的API的應只發送所需的數據。處理描述時沒有意義，需要文件處理。
加考慮數據的多餘量要發送剛剛描述字段
除了前端（說的JavaScript）將需要分析對象，通過僅發送所需要的數據保存時間

考慮這個

{ 
    "id":123, 
    "type":"person", 
    "attributes":{ 
     "name":"John Smith", 
     "dateOfBirth":"2000-01-01", 
     "ssn":123456789 
    } 
}

採取的帶寬相比，這個龐大的數據

{ 
    "id":123, 
    "type":"person", 
    "attributes":[ 
     { 
     "fieldId":"name", 
     "dataType":"string", 
     "value":"John Smith" 
     }, 
     { 
     "fieldId":"dateOfBirth", 
     "dataType":"date", 
     "value":"2000-01-01" 
     }, 
     { 
     "fieldId":"ssn", 
     "dataType":"integer", 
     "value":123456789 
     } 
    ], 
    "relationships":{ 
     "dataType":{ 
     "links":{ 
      "related":{ 
       "href":"http://acme.com/ws/dataTypes/" 
      } 
     }, 
     "data":[ 
      { 
       "id":"string", 
       "type":"dataType" 
      }, 
      { 
       "id":"date", 
       "type":"dataType" 
      }, 
      { 
       "id":"integer", 
       "type":"dataType" 
      } 
     ] 
     }, 
     "field":{ 
     "links":{ 
      "related":{ 
       "href":"http://acme.com/ws/fields/" 
      } 
     }, 
     "data":[ 
      { 
       "id":"name", 
       "type":"field" 
      }, 
      { 
       "id":"dateOfBirth", 
       "type":"field" 
      }, 
      { 
       "id":"ssn", 
       "type":"field" 
      } 
     ] 
     } 
    } 
}

從消費者的角度來看，他們只提供所需的數據作爲迴應和文件中的描述。

不把獨立的呼籲提供更多的細節，這將是非常難以維持，如果你改變的版本

來源

2015-11-19 16:45:22

感謝您分享您的前端視角。這很有道理。 – user2793390

REST API抽象資源屬性？

回答

相關問題