Sumit Verma said the following on 10/05/2010 04:11 PM:
http://<host>/user/[email protected] <mailto:[email protected]>.json also, throws an error:
Endpoint named 'xxx' encountered an unhandled exception.
I was looking at Google's api and seems like they pass all parameter
as query string and the output parameter is in the path. e.g
http://<host>/user/[email protected] <mailto:[email protected]>
http://<host>/[email protected] <mailto:[email protected]>
May be use that format?
Thanks,
Thanks for the suggestion. Based on what I've read and implemented
before, I'm not too keen on query string parameters in general for
REST. The argument is that they aren't very RESTful in nature and that
the user agent (the client to your RESTful service) has to know about
the URI structure since you now have name / value pairs instead of a
/content/item/abc123. If you decide to change the parameter from
"email" to "e" -- you have a to support two APIs now whereas with a
complete RESTful URI (/content/item/abc123) the change is internal to
your API and no clients are affected. (BTW, not a big fan of Google's
API here).
The newer Graph API at Facebook doesn't use query string often (only to
pass OAuth tokens and parameters for the search API). My advice is to
use query string parameters sparsely. We do support query string
parameters in the URIs in case you were wondering. However getting to
the crux of the matter, I'd use UrlEncoded values if you are passing
things like email addresses via REST URIs anyways -- the latest in the
BER of 1.9 supports that.
Moving on to other matters. There is also some impact using reserve
proxies for caching.
http://restpatterns.org/Articles/Caching_Matters
One thing that's worth noting is the effect upon their being a query
string in an HTTP URI has upon caching. You may have heard that a URI
with a query part following a '?' isn't cached. This isn't quite true.
Now, in REST – and hence in HTTP – an identifier is opaque, and a
cache should assume nothing about the resource or its representation
on the basis of there being a ? present. However, historical use of
GET and HEAD in ways counter to REST (specifically, ways which had
side-effects) means that when HTTP/1.1 was developed there was legacy
code that had to be accounted for. Therefore there was a pragmatic
break from REST in ruling that caches should treat responses to such
URIs as uncachable *if there is no explicit caching information*.
Again, we're going to be looking at using explicit caching
information, so this point won't apply to us here.
HTH,
.Peter
--
You received this message because you are subscribed to Mach-II for CFML list.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
***New URLs as of April 29th, 2010***
SVN: http://svn.mach-ii.com/machii/
Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
