rest - Is it always relevant to target RESTful design for a public web service/API? -
no doubt restful buzz word , seems cleaver design pattern in many cases.
struggling apply own web apis (existing , upcoming) wonder if relevant (if forget fact in rfc's try respond ;)).
first of i'm dealing dynamic data determined @ least 3 parameters, possibly 10.
think instance web api performing sound effects , format conversion (equalize, echo, volume, speed, ...). need send credentials, undeterminated set of effect name , settings , sound equalize.
the url effectmaker/echo/10pct/equalizer/20khz/-10pct/output-rate/192kbps/
some parameters in http header (response format instance)
the sound in body.
so, functions defined http methods + url root , parameters in body, url tail , header. not seems convenient, neither me nor developers discovering api.
besides that, caching ability not make sens of users request unique.
so, i'm asking if i'm wrong thinking should try integrate makes sens in rest "philosophy" (stateless, discoverable, ...) use, drop part of pointless (cacheable) or makes api odd? instance should stick http verbs when push data in body , expect converted data in response?
to me seems restfull design makes sens when manage / consume online databases items accessible through quite simple path. when api creates/transforms data unique usage seems inconvenient. when have dozen of parameters accepting various values, seems painfull.
however, soap , xml-rpc standards quite ugly in opinion...
so bad make restlike or asrestasrelevant design associated json parameters/response when seems wiser?
any advice of standard follow in case?
cheers,
vincent
rest not philosophy. it's architectural style - way of designing systems meet goals. if goals aren't yours, rest bad idea. if are, rest idea. don't know goals are, have no idea if rest fit you.
this next bit doesn't have rest, it's more generic web api design,
don't use url contain processing instructions. say, that's totally unwieldy non-trivial systems. either support multipart requests contain processing instructions in 1 part , audio file in part, or treat file upload , processing instructions 2 separate requests. support both.
just spitballing, if trying design restish api, might start near
post /audio-files request: content-type: audio/midi <audio file> response: 201 created location: http://example.com/audio-files/12
-
post /audio-files request: content-type: multipart/mixed; boundary="simple boundary" --simple boundary content-type: application/json; charset=us-ascii { "echo": "true", ... } --simple boundary content-type: audio/midi; charset=us-ascii <audio file> --simple boundary-- response: 200 ok link: <http://example.com/audio-files/12>; rel="audio-file" <altered-audio-file>
-
post /altered-audio-files request: content-type: application/json; charset=us-ascii { "audio-file": "http://example.com/audio-files/12" "echo": "true", ... } response: 200 ok <altered-audio-file>
this treats audio file , altered audio files resources. allows save on wire time holding onto uploaded audio files when wants run 8 transformations on same file, , gives option hold onto altered audio files if later choose so. if want track requests, adding third endpoint, maybe /audio-requests
.
Comments
Post a Comment