REST API Accept header json/pdf -


i'm working api, think doing wrong implementation of rest api.

we have following endpoints

  1. get v1/{organizationid}/invoices
  2. get v1/{organizationid}/invoices/{guid}

when first, invoices, if second endpoint, without accept: application/json header, response first endpoint instead.

the company, provides api, says reason because second endpoint can give both json , pdf output, seem pdf be

get v1/{organizationid}/invoices/{guid}/pdf 

besides that, if send malformed guid, full blown html 404 error page instead of, e.g., blank page or error message.

to sum up

  1. is 2. endpoint handled properly?
  2. is valid make pdf output json/xml?
  3. shouldn't new endpoint instead?
  4. is html allowed error response, malformed request?

some people don't categorize rest-based questions "right" , "wrong", go ahead anyway:

  1. no, second resource should return representation of second resource, is, invoice, never collection of invoices.

  2. yes, ok potentially return multiple representations of same "thing". invoice can conceivably return both json , pdf, , can select correct 1 based on "accept" header.

  3. no, shouldn't new "endpoint", because these "things" not "endpoints", resources. invoice resource, json document "representation" of resource.

  4. yes, error response can contain body, whatever representation server comfortable sending. server should of course orient using "accept" header client, not required so.

a few remarks: should not possible get invoice wrong guid, since these resources should linked collection resource. when client follows links (as should), there should no way follow link wrong guid.

it wrong return different resource (invoice collection instead of invoice), ok have multiple representations of same resource. if there no "accept" header, server should pick one, or indicate 406 not acceptable.

one small point: mime-type should not application/json, because how know it's invoice then? should like: application/vnd.someprovider.invoice+json. no 1 bothers mime-types these days, mention completeness sake.


Comments

Popular posts from this blog

java - Static nested class instance -

c# - Bluetooth LE CanUpdate Characteristic property -

JavaScript - Replace variable from string in all occurrences -