We're using LinkedIn API for a very simple case:
authenticate (either through SDK or web view)
use token to fetch profile
Today we have noticed a huge degradation of service. Simple profile calls response time is in the range of 500ms - 12000ms and sometimes it returns 500.
Slow response can be easily reproduced by using the REST console from developers guide:
https://apigee.com/console/linkedin
with more than half of the requests taking more than 10sec to respond.
We also noticed tha sometimes requests return 500 from LinkedIn:
<-- 500 https://api.linkedin.com/v1/people/~:(id,first-name,last-name,email-address,formatted-name,headline,location,industry,num-connections,num-connections-capped,summary,specialties,positions,phone-numbers,public-profile-url,picture-url,picture-urls::(original))?format=json (17808ms)
{
"errorCode": 0,
"message": "Internal API server error",
"requestId": "3FXP4W2HD2",
"status": 500,
"timestamp": 1519643223202
}
<-- END HTTP (138-byte body)
This looks like a timeout on server side maybe at some point, hence failure.
Given that sometimes the API responds quickly, it does feel like one of the servers outage maybe? (I might be wrong).
Would be great to know if:
there is a status page for the LinkedIn API that can tell us about the problems and how / when they are getting addressed.
can we treat V1 API as reliable at all? There was a similar (but easier to workaround) problem with fetching profile just couple of weeks ago.
Related
Running into an issue when trying to call the Posts API.
I'm getting a list of the authenticated user's posts through https://api.linkedin.com/rest/posts?q=author&author=AUTHOR_URN (https://learn.microsoft.com/en-us/linkedin/marketing/integrations/community-management/shares/posts-api?view=li-lms-2022-07&tabs=http#find-posts-by-authors) which worked yesterday but not anymore today.
I am convinced I changed something between then and now, but whatever I do I cannot seem to get the request to work anymore.
The error returned does not give me a lot of information either:
{
"message": "Internal Server Error",
"status": 500,
"code": "INTERNAL_SERVER_ERROR"
}
I also created a request to fetch images yesterday, which does still work:
https://api.linkedin.com/rest/images/ids=List(IMAGE_URN) (https://learn.microsoft.com/en-us/linkedin/marketing/integrations/community-management/shares/images-api?view=li-lms-2022-07&tabs=http#batch-get-images)
URN I'm using for the /posts request is formatted as follows: urn%3Ali%3Aorganization%3A<REDACTED> (where <REDACTED> is the numeric author identifier).
Confirmed the headers are the same between the /posts request and /images request.
Headers for reference:
Authorization: Bearer ACCESS_TOKEN_REDACTED
X-Restli-Protocol-version: 2.0.0
LinkedIn-Version: 202207
Is there anything I'm missing here that I need to get my /posts request working?
Thanks in advance!
Talked to someone from LinkedIn support since the issue occurred for me. Their response:
It's possible that you were getting that error due to a small hiccup on our side at that time - This can happen when we deploy updates or fixes.
Since then I've not seen this happen anymore, so expecting this is the case. Closing as answered.
I am trying to make an API call to Microsoft Graph using the Microsoft Logic App HTTP connector. The call fails with the error:
"BadGateway. Http request failed as there is an error getting AD OAuth token: 'Failed to extract error details from response content ''.'.".
I have been trying many things including being able to run the call successfully via Postman. I have decrypted the Postman token with jwt.ms and verified certain values such as:
"aud": "https://graph.microsoft.com",
"iss": "https://sts.windows.net/{{tenantId}}/",
I went through stacks of Google searches, and as for Stack Exchange, these are the closest matching posts that I could find.
Http request failed as there is an error getting AD OAuth token: 'AADSTS50001: The application named https://management.azure.windows.net
In this case the audience paramater was wrong, and in my case I have tried many, and not really sure anymore which is the correct one, even though none of them worked for me when tested.
Azure Logic App HTTP action authorization fails
The post deals with a shared key use case. My current requirement for this project is to use OAuth.
Secure access and data in Azure Logic Apps
I have tried the following for "Authority":
"authority": "https://sts.windows.net/{{tenantId}}/"
"authority": "HTTPS://login.microsoftonline.com/{{tenantId}}/"
"authority": "HTTPS://login.microsoftonline.com/{{tenantId}}/oauth2/v2.0/authorize"
This is the screen that shows the HTTP connector inside the logic app.
This is the same connector at runtime.
This is the raw HTML that the HTTP connector generates.
Hoping someone can spot where I am going wrong.
Is there a way to implement a "delivery receipt", or, "quick response", from the server before the start of a long running process (that will delay the actual response content)?
I mean this:
request -> server receives -> res.send(200) ((but keep this 'res' alive!)) -> server long running process -> res.send("actual response")
This would be very useful in the app side, so I get to know that timeouts are really happening because of the process and not because the server is offline. Also, I wanted to avoid making two requests, one following the other one.
HTTP Status Code 100 CONTINUE can be used for this purpose. See https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1
According to the RFC, 100 Continue is an interim response which must be followed by a final response once the request has been completed.
Lets say I have an API endpoint that executes some business operation which can result in many different failures that are not connected directly to the request.
The request is correctly formed and I cannot return 4xx failures, but the logic of the application dictates that I return different error messages.
Now I want the client to be able to differentiate these error messages so that different actions can be taken depending on the code. I can return a custom JSON like this e.g.
{
"code": 15,
"message": "Some business error has occurred"
}
Now the question is which HTTP status code should I use for such occasions if no standard code like Conflict or NotFound makes sense.
It seems that 500 InternalServerError is logical, but then how can I additionally flag that this cannot be retried, should it be just documented that given status codes is not possible to retry so one can retry if you don't get one of those?
Consult RFC 7231:
503 Service Unavailable looks like a potential candidate, but the RFC mentions that this is supposed to represent a problem "which will likely be alleviated after some delay." This would indicate to a client that it could try the same call later, maybe after business hours or on the weekend. This is not what you want.
501 Not Implemented could be possible, but the RFC mentions "This
is the appropriate response when the server does not recognize the
request method and is not capable of supporting it for any resource. A 501 response is cacheable by default;" This does not appear to be the case here - the HTTP method itself was presumably valid - the failure here seems to be happening at the business rules layer (e.g. sending in an account number that is not in the database), rather than an HTTP method (GET, POST, etc.) that you never got around to implementing.
That leaves the last serious candidate,
500 Internal Server Error
The 500 (Internal Server Error) status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling
the request.
This is the error code that is normally used for generic "an exception occurred in the app" situations. 500 is the best choice.
As to how to distinguish this from a "temporal internal trouble" error, you can include this as part of the HTTP body - just make sure that your client can parse out the custom codes!
Status code 400 Bad Request is used when the client has sent a request that cannot be processed due to being malformed.
Status code 404 Not Found is used when the requested resource does not exist / cannot be found.
My question is, when a client sends a request to an endpoint my API does not serve, which of these status codes is more appropriate?
Should an endpoint be considered a "resource", and thus a 404 be returned? My issue with this is that if the client only checks the status code, they cannot tell the difference between a 404 indicating that they got to the correct endpoint, but there was no result matching their query, versus a 404 indicating that they queried a non-existing endpoint.
Alternatively, should we expect that a client has prior knowledge of all available API endpoints, and thus treat their request as malformed and return a 400 if the endpoint they are trying to reach does not exist?
Maybe this depends on whether the endpoints are REST or not. If they are REST endpoints, the client should not need prior API knowledge, but be able to learn about all relevant API endpoints by navigating the API from a single root endpoint. In such a case, I guess 404 would be more appropriate.
In my specific case right now, this is an internal (non-REST) HTTP API, where I expect the client to have prior knowledge of all API endpoints, so I am leaning towards 400, to avoid issues where 404 from accessing the wrong endpoint could be misconstrued as a 404 indicating that what they sought from the correct endpoint could not be found.
Thoughts?
As a convenience, many modern APIs provide human-readable endpoints for developer convenience. The intent of REST, however, is that URLs are treated as opaque - they may happen to contain semantic content, but can't be relied upon to do so. There's no such thing as a "malformed" URL. There's only a URL that points to something and a URL that doesn't.
Now, that's the REST dogma (and arguably also the HTTP 1.1 spec). That doesn't mean it's what you should do. If you have a single internal client for your API, and that's not going to change, you have a lot of flexibility in designing your own standards. Just make sure to document them, especially those that might confuse the guy straight out of college that they hire to replace you when you move on.