SFDC-MC-REST-Style-Guide
SFDC-MC-REST-Style-Guide copied to clipboard
Content negotiation (csv export)
Got this request from today from one of the feature teams:
hi, we are thinking about a simple CSV data export. do you think this would be appropriate to add to our data API endpoints as a different datatype? currently we support json, but I was wondering if CSV could be a data format. [2:14 PM] Jeff Fitzgerald: i'll follow up with my indy folks about how we would ask for that format. we revised our api style guide last week
I think we touched on this briefly on Friday, but I don't remember us ever coming to a resolution.
- Use .csv at the end of the url.
- Content negotiation via Accept header.
- Some other query parameter. The "correct" way is probably my least favorite of the bunch.
This kind of request comes from confusion on what an API actually is, i.m.o. An API would provide the data necessary to construct the CSV export, which would be constructed outside of the API, perhaps in a middle tier ASP site, for example. This is my opinion on the matter.
The decision was "no content negotiation". "Binary views" where discussed.
Doug's objections are * CSV implies codepages and not UTF-8 by default. Localization of data would not spotty. * CSV is a weak format. New lines in data are difficult for example * Exposing CSV in the API is a poor separation of concern for importing * Summed up by https://xkcd.com/1481/
Personally I take money and would expose CSV as a "binary view" of a resource.
In our c# code base Doug argues that CSV is better as a "aspx". Personally, I'm not as convinced but have trouble dismissing Doug's thoughts.
Agree with the money point. Our customers are asking for it in the new product, and they be the ones with the dough.