Why no path or query parts in the API target URL configuration?
There's probably a good reason for this, but why is it that the "API Hostname cannot contain path or query parts."
With Twitter's announcement of API versioning, Apigee would let me change all my mashups all at once just by prepending "api." to the TLD and appending "/1" to my current "http://twitter.com" API endpoint. This kind of flexibility would be one more cool way in which Apigee makes my life better.
With Twitter's announcement of API versioning, Apigee would let me change all my mashups all at once just by prepending "api." to the TLD and appending "/1" to my current "http://twitter.com" API endpoint. This kind of flexibility would be one more cool way in which Apigee makes my life better.
2
people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
-
Inappropriate?this is definitely a direction we could take.
our philosophy at the start was to keep the concept of the proxy tied to the top level domain so that the URLs would be familiar and deterministic. The TLD assumption also allows us to keep a few aspects of the UI interactions simple.
but there are many cases where the flexibility offered by your solution would be valuable.
this is a strong candidate for us to consider.
I’m thankful
-
Inappropriate?From Chad via email
one thing that I noticed was that I can't use your service with tumblr read api.
they have a unique structure (but i have seen it before on a few other API's):
http://(username).tumblr.com/api/read
so what im thinking is maybe you guys could add an expression in your domain settings that would do this:
for example im mapping (userapiname) to tumblr.com
http://(customsubdomain).(usersapiname).apigee.com
a request to:
http://(customsubdomain).(usersapiname).apigee.com/api/read
could be a request to:
http://(customsubdomain).tumblr.com/api/read
this would allow your system to be much more flexible, hopefully this is possible. -
We're addressing this in our Monday design meeting. -
Chad, we're still finalizing the details. I'll post our proposed solution as soon as I can. Thanks for following up. -
Chad, this is a great requirement for us to chew on. Your proposal looks great. Like Marsh said, we're going to work on the details. It was great talking with you at the PayPal conf. -
Inappropriate?To recap, there are two issues in this thread:
1) Whether paths can be specified as part of the proxy endpoint, rather than just the domain, which would help with the Twitter versioning situation.
2) Support for APIs like Tumblr's which don't exactly conform to REST (e.g. the username is part of the domain rather than a parameter to a constant API endpoint).
#1 is likely to be implemented earlier. As for the specific case in #2, Tumblr announced support for the Twitter API, which might be serve as a stop-gap solution in the interim. I promise that we are tracking both of these issues in our product backlog and hope to get to them as soon as possible. -
Inappropriate?Is there any word on when solution 1 is being implanted?
-
Hi Jochem,
This was part of our last sprint, which just wrapped up. Unfortunately we couldn't get to it in time.
But personally, this is a feature near and dear to my heart, so I promise we'll keep at it! Hope to have some updates for everyone soon (as a general rule we don't promise dates).
Loading Profile...




EMPLOYEE
EMPLOYEE

