Dudes, this is so not REST

Re:Dudes, this is so not REST by nikcub on Tuesday March 15, 2011 @02:55PM (#2328866)

if you don't want to use content negotiation, then stuff it into query parameters - that is what most API's do (and most that support full content negotiation do anyway)

eg.?v=1&format=xml

but interesting to note is that why is encoding easy to do as part of content negotiation, yet everything else is hard? you never see ?e=UTF-8 or &c=gzip

[ Parent | on HN ]

Re:Dudes, this is so not REST by pzb on Tuesday March 15, 2011 @03:47PM (#2329066)

Many APIs simply specify that the encoding is constant (always UTF-8) so this is not an issue. And many HTTP libraries simply handle the content encoding transparently.

The challenge is some HTTP library APIs commonly used for developing clients offer the following interface: - GET $URL

If you are lucky, then it might also support POST and offer a second parameter for the request body. If are really lucky, there is a way to specify arbitrary methods, but this is fairly rare.

[ Parent | on HN ]

Re:Dudes, this is so not REST by wahnfrieden on Tuesday March 15, 2011 @05:13PM (#2329417)

I'm all in favor of supporting fallbacks for more limited clients. But query params are not a great idea since they can prevent caching from happening.

[ Parent | on HN ]

Re:Dudes, this is so not REST by kevinstubbs on Wednesday March 16, 2011 @02:01AM (#2331023)

Add a random number to the end as a param to force no-caching.

[ Parent | on HN ]

Re:Dudes, this is so not REST by wahnfrieden on Wednesday March 16, 2011 @02:04AM (#2331032)

My point was that it's not a good thing for requests for cacheable content, that might not be cached since you used a query param to access it. Some caches ignore requests with query params since "queries" are often not static.

[ Parent | on HN ]