Loading Profile...
Does Apigee "wrap" errors at the API provider level with debug info?
As an API consumer, if I receive an error message when accessing an Apigee-proxied API, how can I tell if the error is from the provider or from Apigee? Does Apigee "wrap" provider errors with information on what "service layer" the error occured?
This will help debug things (not like the Twitter API ever throws errors...).
This will help debug things (not like the Twitter API ever throws errors...).
I’m uncertain
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?Thanks, Marsh. This is a great, core problem & suggestion for us to tackle.
We added it to our backlog. Once we get a draft of a design, we'll run it by you.
In the meantime, Manoj might have some tips about how to discern if errors are coming from Apigee. -
Inappropriate?Hello Marsh,
Thats a good question.
As a proxy there are two categories of errors for apigee.
1) Provider Errors
- As a proxy apigee will relay any http error code and the error payload it receives from the provider
2) Apigee Specific errors : they can be categorized as
- policy enforcement errors
- the http error code is 403 and the http payload indicates that the user exceeded his limit.
- in the next rev user can specify his own http error code and message
- provider unavailable
- we return a http message cleary saying that apigee was not able to connect to the provider and http return code is 503
- system errors
- returns http return code 500 and http message indicating apigee failure
Hope that answers your question: -
Inappropriate?In a design session yesterday we crafted the following solution proposal for addressing this issue:
People: API Consumers, API Providers
Problem: It is difficult or impossible to know if an API request failed because of Apigee or failed because of an actual API endpoint failure.
Proposed Solution: Add data to the response header that indicates whether or not Apigee is causing the failure.
Response Header: Apigee-Status
Possible Response Values: Success, Error
I’m thankful
1 person says
this answers the question
-
Inappropriate?Brian, your proposed solution is the right idea, but may I suggest tweaking the names of the header and/or responses to eliminate any ambiguity?
An important use-case is when the 1st part API is down (looking at you, Twitter!), and I need to debug. I don't want to have to re-point my API calls from my Apigee mapped API to the 1st party, so the header needs to tell me whose fault the failure is, Apigee or 1st party. (BTW, if it's Apigee's fault, there's a good chance that I'm not getting the additional header info, right?)
At one level this is a question of Apigee's status. But at another level, I want confirmation that the request was passed on to the 1st party, which is where it died. So in that light, are there better words for the header/response to communicate this?
Otherwise, I think it's a good solution.1 Comment Add a comment
This answers the question
-
awesome. this is great stuff. thanks, Marsh. -
Inappropriate?This is of fundamental concern to us also. Right now we are considering any transport-layer errors as Apigee errors but anything else as a service provider error.1 Comment Add a comment
This answers the question
-
thanks for the +1, Mike. The engineers are developing & testing this feature right now.
EMPLOYEE
EMPLOYEE
