SmartDroidDeveloper / google-api-java-client

Automatically exported from code.google.com/p/google-api-java-client
0 stars 0 forks source link

Lift URL template filling code into GoogleUrl so it can be reused. #82

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Version of google-api-java-client (e.g. 1.2.1-alpha)?
head

Java environment (e.g. Java 6, Android 2.2, App Engine 1.3.7)?
all

Describe the problem.
The method ....googleapis.json.GoogleApi.buildRequest() contains a useful bit 
of code for expanding a url template from a map of parameters.   We could lift 
that up to http.GenericUrl to make it usable in more contexts.

How would you expect it to be fixed?

Exactly as described.  Lift the reusable code into a base library class.

Original issue reported on code.google.com by ai...@google.com on 21 Dec 2010 at 10:28

GoogleCodeExporter commented 9 years ago
We might consider implementing a subset of the URL Template specification, 
which includes our own Joe Gregorio as one of the authors:

http://tools.ietf.org/html/draft-gregorio-uritemplate-04

For now, for our needs though it might be sufficient to just make a reusable 
method in GoogleApi that exposes just enough to build the URL templates subset 
based on Google's Discovery API as is already implemented now.

Tony, do you want to implement this yourself?

Original comment by yan...@google.com on 22 Dec 2010 at 2:23

GoogleCodeExporter commented 9 years ago
As gratifying as it sounds to implement the full specification, if we are not 
going to use it, it will only be dead weight in the library.   I would opt to 
do expose just what we need right now, and enhance as needed.

But, for enhancements, a few pop up as potentially useful soon.
1. {list*} expansion might be potentially useful as a poor-man's command 
batching.    E.g.   /service/resource/get/id1,id2,id3,id4,.....
2. {var=default} might be useful in APIs where a userId appears very often, and 
the default would be a magic constant which means 'yourself'.

I'll take a look at it.  It may not be all that much code to provide the full 
implementation.

Original comment by ai...@google.com on 22 Dec 2010 at 9:07

GoogleCodeExporter commented 9 years ago
I looked at the URL Template specification and found enough corner cases to 
worry me about doing it at this time.  In particular, I'm concerned about the 
exact semantics of when we % encode the URL according to the spec vs. how the 
library does it today.  I'ld rather split the expansion out now, then face the 
semantic issue in a separate change.

Original comment by ai...@google.com on 4 Jan 2011 at 8:07

GoogleCodeExporter commented 9 years ago

Original comment by yan...@google.com on 8 Jan 2011 at 6:19

GoogleCodeExporter commented 9 years ago

Original comment by yan...@google.com on 26 Jan 2011 at 3:09

GoogleCodeExporter commented 9 years ago

Original comment by ai...@google.com on 26 Jan 2011 at 9:05

GoogleCodeExporter commented 9 years ago

Original comment by yan...@google.com on 18 Feb 2011 at 1:20