Yeah, let's do CORBA once again. No thanks.
Well, it wouldn't be so bad if it were universal enough, but we'd probably have to wrap it in some sort of inter-ORB protocol for the internet or something...
Stop Writing REST API Clients
41–50 of 137 posts
Re: Stop Writing REST API Clients
#42Am I the only one who doesn't like receiving direct orders from article titles?
Writing using authoritative language is very common, and widely considered a best practice.
I highly recommend you simply accept it as what it is: the way some people communicate, especially online. It's not worth your time/attention/care to think about this.
Re: Stop Writing REST API Clients
#43How about stop calling REST something that is not. You'll be surprised how many things it will solve.
Re: Stop Writing REST API Clients
#44Am I the only one who doesn't like receiving direct orders from article titles?
Try reading that with the voice of Morgan Freeman. Now THAT is something you would likely do :)
Re: Stop Writing REST API Clients
#45Am I the only one who doesn't like receiving direct orders from article titles?
Writing using authoritative language is very common, and widely considered a best practice. I highly recommend you simply accept it as what it is: the way some people communicate, especially online. It's not worth your time/attention/care to think about this.
Yes, you're right
But it still looks like they pulled some rules out of nowhere and are enforcing them.
Re: Stop Writing REST API Clients
#46Hmmm....JSON documents (jsonSpec) describing the restful services is the new WSDL, feels like 2002 all over again. I think too many people consume REST APIs in different manners, utilizing different data in unique relations. This is the beauty of it.
Well, to be fair, JSON is at least a lot less verbose than WSDL. So there's that.
Re: Stop Writing REST API Clients
#47Am I the only one who doesn't like receiving direct orders from article titles?
It irritates me too.
Re: Stop Writing REST API Clients
#48Substitute "XML" for "JSON" and we've now come full circle. The point about REST is that it is self-describing. And ideally should be using the same URIs as the version people clicking around in Firefox or Chrome see. The API is just the XML or JSON or whatever is flavour of the week version of the HTML version. (Or we could use embedded data—microformats, microdata, RDFa—and get rid of that distinction.)
I don't think there is a well-known way to self-describe available and required parameters nor any other validation requirements, or am I wrong?
Re: Stop Writing REST API Clients
#49Re: Stop Writing REST API Clients
#50Substitute "XML" for "JSON" and we've now come full circle. The point about REST is that it is self-describing. And ideally should be using the same URIs as the version people clicking around in Firefox or Chrome see. The API is just the XML or JSON or whatever is flavour of the week version of the HTML version. (Or we could use embedded data—microformats, microdata, RDFa—and get rid of that distinction.)
Agreed. I came here to post something similar but I was going to mention working with SOAP[1] in addition to what you mentioned. It sounds like the OP is trying to do something which sounded very much like using SOAP and XML to me.
To paraphrase the OP, "Since so many APIs can be described in similar terms, why don't we have some sort of standard that one can look at to identify how to use the API instead of letting the API speak for itself?"
When you start going down this track, you're not only making things complicated on the client's end of things. On the server side, you're having to maintain two things for the API now. First: the ruleset, ensuring it's 100% to spec lest a client fail. Second: the code generating the response in the first place.
I've built clients and servers for both RESTful and SOAPy APIs and I can say I would take REST any day.