Ironic that the author's homepage (http://steveklabnik.com/) is a confusing pretend console that takes several seconds (on every visit!) to reveal useful information.
Nobody Understands REST or HTTP
131–140 of 141 posts
Re: Nobody Understands REST or HTTP
#132Earlier quoted context omitted.
Upvoted because I like your solution for pagination and for further information via an :href attribute. However, I don't see a real problem with the way Rails does things because it's "by default" and I think a dev ends up causing a lot of unnecessary trouble for himself by using stock to_json. The more I work with Rails building out a JSON API, the more I realize that .to_json is just another way to "scaffold" - it'…
I can see that point ... but where's the direction on what to do next? What's the post-scaffold JSON mechanism? Bonus points if it lets me generate/embed urls with the knowledge/techniques I have from making web pages. If you say "erb", please don't be offended by me laughing.
Oh please ;) Don't hate on the ERb. It's fine for something like this.
OK, I am only half-kidding. Have you seen RABL? I've been meaning to play with this. http://blog.dcxn.com/2011/06/22/rails-json-templates-through...
Looks perfect.
Re: Nobody Understands REST or HTTP
#133Earlier quoted context omitted.
First off, thanks for taking the time to reply to my admittedly baiting post. I do have a serious point I'm making though. Lets walk through it. http://www.mywebsite.com/api/getAllPageNames/returnType/JSON In this string 'get' appears once. However, as an experienced dev, you know that this is a GET request. To you it looks redundant. However to someone trying to understand what will happen when they hit enter with t…
But you still have to make a GET request and hence understand what that verb does - so you don't really gain anything - and now you're creating ambiguities for the API users. What if I POST to 'getAllPageNames'? It doesn't make sense, does it? Personally, I'd say that if a developer can't be bothered to read the whole nine(!) verbs of HTTP, he shouldn't use the API. I mean, GET is described in just 11 lines! And (s)h…
I agree! Making such api make it really confusing. And what if one have to support other verbs. Then, One will end creating apis for each verb. A programmer who is using this APIs knows about HTTP and he knows about verb..making it explicit in the url will make confusing for most developers.
Re: Nobody Understands REST or HTTP
#134Excellent article... We followed all of these Rest principals when we designed apis for HP cloud print (i think it will soon become public)..except
1) Representing all resources with noun - We had a tough time representing all resources with Noun. One of our APIs is Post on \PrintJobs\ - creates a new print job
But printing can only start when all the data (content to be printed) is uploaded on the server. So client needed an API to tell the server that it can start printing..something like this..
\printjobs\1\print \printjobs\1\cancel
one way we thought to avoid this was to have a represent it job state and client can change them like this..
\printjobs\1 Put :
But there are cons
1. These were not actually states, these were actions(verbs)..because state would be initialized, printing etc.. so if client does Get after making it Put..it will get "printing" not "Print".
So we were tangling with keeping semantics clear and making it easy at the same time. Hence we went with these resources. Do you think it could modeled better?
2) When we think of versioning, we always assume that only the representation can be changed..why not behavior? Take for e.g. if api implementation changes but not representation..clients may be dependent upon the implementation (i know this is bad! since implementation details are getting leaked out from the API)
Thoughts?
Re: Nobody Understands REST or HTTP
#135Earlier quoted context omitted.
yes i'm thinking more pragmatically. From an API perspective the header is part of the request but given that the human-readability of urls is a feature of http, it just somehow feels wrong to me to modify the response based on a request header.
I think most developers don't see that as a problem. We modify the response all the time based on headers like User-Agent, Referer, If-Unmodified-Since, Accept-Language and others, so using Accept for versioning isn't really that strange.
User-Agent: modifying based on this is a Bad Thing
Referer, If-Unmodified-Since: these only decide if you respond or don't or error, they don't generally change a successful transfer
Accept-Language: I was under the impression that this was buggy and not well-supported, but it is a good example in theory
Re: Nobody Understands REST or HTTP
#136You can't satisfy the HATEOAS constraint by simply returning URLs in the JSON response from your API. The structure of the data is still tightly coupled to your own application, and so must be any client that can make use of it.
It is essential that RESTful applications be able to evolve independently from the client. To allow this, they must use forms of hypermedia generic enough to serve as the engine for all present and future versions of the application. If the client has any code specific to your app, then your app is not RESTful in any scope beyond its own.
I'm not convinced that the whole resource vs action thing is all that important to REST. It's an ideal that has been largely ignored in practice and the web has been quite successful without it. Contrast this with HATEOAS which has been the unavoidable reality of the web since day one.
Re: Nobody Understands REST or HTTP
#137Earlier quoted context omitted.
Looking at the newer spec, we should be able to use "hreftype" for content type or "hreflang" for accept language: http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#s_hyper... I don't know if any browser will implement this or has implemented it, but in real world scenarios we'll probably have to stick with .csv and en/foo or ?locale=en for a couple of years...
XHTML2 is never coming. That train has left its station with HTML5. So long, elegance and ideals! At least I have my ruddy practicality here.
[deleted]
Re: Nobody Understands REST or HTTP
#138Is there any way to make the browser do an Accept: application/csv header on a hyperlink? I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv) While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.
Looking at the newer spec, we should be able to use "hreftype" for content type or "hreflang" for accept language: http://www.w3.org/TR/xhtml2/mod-hyperAttributes.html#s_hyper... I don't know if any browser will implement this or has implemented it, but in real world scenarios we'll probably have to stick with .csv and en/foo or ?locale=en for a couple of years...
XHTML2 is dead, but the current HTML5 spec includes a 'type' attribute: http://www.w3.org/TR/html5/links.html#attr-hyperlink-type
Re: Nobody Understands REST or HTTP
#139Earlier quoted context omitted.
I think most developers don't see that as a problem. We modify the response all the time based on headers like User-Agent, Referer, If-Unmodified-Since, Accept-Language and others, so using Accept for versioning isn't really that strange.
User-Agent: modifying based on this is a Bad Thing Referer, If-Unmodified-Since: these only decide if you respond or don't or error, they don't generally change a successful transfer Accept-Language: I was under the impression that this was buggy and not well-supported, but it is a good example in theory
The response is changed all the type depending on the value of the Cookie header.
Re: Nobody Understands REST or HTTP
#140I thought I finally had REST figured out until I read this. Does anyone else see a diminishing return on pedantically following the REST-prescribed design and actually creating an API that people are familiar with out of the gate? I feel like if I followed this article to the T in my current design, anyone trying to integrate with it would spend so much time reading my API documentation just to figure out why they we…
Part of the problem is that the fundamental idea behind REST has more depth to it than most developers care to understand, so the parts that most designers, developers and consumers of "REST" APIs think they are in love with is a rather superficial part of it.
This makes things really confusing when people talk about REST because you can't really know what they mean by it.