Re: How much REST should your Web API get?

Jan Algermissen <[email protected]> Thu, 2 May 2013 22:09:15 +0200
Newsgroups gmane.comp.web.services.rest
Message-ID <[email protected]>
On 02.05.2013, at 21:58, Mike Schinkel <[email protected]> wrote:

>> It's also pretty straight forward, actually. I have never understood the reluctance people have to put they semantics they need done in a media type - right where REST wants them to be. <shrug/>
> 
> I disagree that it is "easy."

Wait, I did not say 'easy' :-)

>  Building a good media type takes a lot of architecture skill (IMO) to get it right,

Of course - like building a good API does. Doing the media type is *the* design activity in REST - put someone on the job who knows what she is doing :-) As you would for an API in the OO world. Eh?

> without requiring constant and ongoing revisions which pretty much moots the benefit.
> 
> Also (IMO) I don't think there is a real value unless the media type is shared by a lot of users (which also argues against media type proliferation.) For example if FreshBooks, Wave, Xero, Kashoo, Outright, FreeAgent, Harvest etc. each were to all create their own media type for their own web APIs they would not provide much value over hardcoded URLs.

Oh, of course they would:

[1] Aiming at converging some of the types in the long run is at least approachable. Forget that with APIs. Re-use sometimes goes against corporate strategy, but why not image a generic shopping mobile app that can work with many shops using a single media type. Wouldn't shop X have a reason to want to enable that app too? What about price search engines?

> OTOH if they all got together and created an "application/accounting" media type then I could see huge benefit.  (Hmm.  Maybe there is something there...)

Well, that's the 'unified data model' discussion from the 90ies. Not gonna happen :-) But, consider this: REST leaves exactly one spot where you can put your semantics, that is the media type (and link rels for that matter, I keep lumping these together). The rest of REST (hah!) is uniform. Having variation take place in only one spot greatly simplifies integration (much easier to convert yourOrder.xml to myOrder.json than it is to have yourOrderAPI-client talk to myOrderAPI.)

Jan


> 
> -Mike



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/rest-discuss/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/rest-discuss/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/