Blogger API Gives Error 500 when Requesting List of Scheduled Posts - api

I am using Blogger API v3. When requesting a list of scheduled status posts, the API always returns error 500. First I thought it might just be my blog or my app. However, I've tested on the API's own website (try it out) on a newly created blog and it still happens. Does anyone else have this same problem? Thanks in advance.
EDIT: Of course, this is assuming you already have scheduled posts in your blog though.

The 500 Internal Server Error is a very general HTTP status code that
means something has gone wrong on the web site's server but the server
could not be more specific on what the exact problem is.
Reference : https://www.westhost.com/knowledgebase/display/WES/What+Is+A+500+error
Q : Does anyone else have this same problem?
A : Yes, I have, several times.
In fact, the 500 error is not only happen when we request a list of posts but also in every request we can make with Blogger API. AFAIK, when I do a request with Blogger API and it's returned 500 error, it's always because when doing multiple request in almost the same time (usually because of looping which I forgot to break)
I've also encounter this error when testing it straight from the Blogger API examples page. The first time I request it retured 500 error, but the second time, the request the returned the data that I requested.
For the sample in Blogger API site, it may be just an authentication error. As for the error by your own request, I suggest you to check your coding again, the the request may be placed inside a looping or you've send a request BEFORE the previous request has successfully returned a response.

Related

Why is adBudgetPricing linkedin API returning status 404 with message 'Resource adBudgetPricing does not exist'?

I am new to using linkedin APIs and all I am trying to do is use this API to make a GET request
https://api.linkedin.com/v2/adBudgetPricing?account={AccountNumber}
however, it keeps returning status 404 with 'Resource adBudgetPricing does not exist'
What could I be doing wrong?
Linking official docs here--
https://learn.microsoft.com/en-us/linkedin/marketing/integrations/ads-reporting/ad-budget-pricing?tabs=http#find-pricing-insights-by-criteriav2
I was finally able to get this working for myself with the aid of one of LinkedIn's sales engineers. I was also able to replicate your issue while debugging when I left of the required q parameter. If you don't set q=criteriaV2, then you'll receive a 404.
Make sure that you're sending all of the required parameters in your request:

REST API: What HTTP return code for no data found? [duplicate]

This question already has answers here:
What is the proper REST response code for a valid request but an empty data?
(28 answers)
Closed 1 year ago.
If someone could please help settle this argument we might actually get this system finished LOL :^)
So, if you have a REST API.. for.. say.. returning patient details...
And you send in a request with a patient id...
But no patient with that patient id actually exists in the database..
What response should your API return?
1. a 404 ?
2. a 204 ?
3. a 200 with something in the body to indicate no patient found..
Thanks
Use a 404:
404 Not Found
The server can not find the requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean
that the endpoint is valid but the resource itself does not exist.
Servers may also send this response instead of 403 to hide the
existence of a resource from an unauthorized client. This response
code is probably the most famous one due to its frequent occurrence on
the web.
From MDN Web docs https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
What response should your API return?
It Depends.
Status codes are metadata in the transfer of documents over a network domain. The status code communicates the semantics of the HTTP response to general purpose components. For instance, it's the status code that announces to a cache whether the message body of the response is a "representation of the resource" or instead a representation of an error situation.
Rows in your database are an implementation detail; as far as REST is concerned, there doesn't have to be a database.
What REST cares about is resources, and in this case whether or not the resource has a current representation. REST doesn't tell you what the resource model should be, or how it is implemented. What REST does tell you (via it's standardized messages constraint, which in this case means the HTTP standard) is how to describe what's happening in the resource model.
For example, if my resource is "things to do", and everything is done, then I would normally expect a GET request for "things to do" to return a 2xx status code with a representation announcing there is nothing to do (which could be a completely empty document, or it could be a web page with an empty list of items, or a JSON document.... you get the idea).
If instead the empty result set from the database indicates that there was a spelling error in the URI, then a 404 is appropriate.
It might help to consider a boring web server, and how retrieving an empty file differs from retrieving a file that doesn't exist.
But, as before, in some resource models it might make sense to return a "default" representation in the case where there is no file.
if you have a REST API.. for.. say.. returning patient details...
Is it reasonable in the resource model to have a document that says "we have no records for this patient"?
I'm not a specialist in the domain of medical documents, but it sounds pretty reasonable to me that we might get back a document with no information. "Here's a list of everything we've been told about this patient" and a blank list.
What response should your API return?
If you are returning a representation of an error - ie, a document that explains that the document someone asked for is missing, then you should use a 404 Not Found status code (along with other metadata indicating how long that response can be cached, etc).
If you are returning a document, you should use a 200 OK with a Content-Length header.
204 is specialized, and should not be used here. The key distinction between 204 and 200 with Content-Length 0 is the implications for navigation.

MS SharePoint HTTP REST API getFileByID(): 500 Internal Server Error

I'm seeing sporadic (periodic) 500 responses for SharePoint API requests that I cannot explain. The problem endpoint is in the form:
https://<mytenant>.sharepoint.com/sites/<mysite>/_api/web/getFileByID('a8fda9ec-016f-41e6-9c3e-6aacbe57797e')?$select=Author/Title,Author/LoginName,Author/Email,Author/AadObjectId/NameId,UniqueId,Name,Length,ServerRelativeUrl,TimeLastModified,ListItemAllFields/RoleAssignments/Member/PrincipalType,ListItemAllFields/RoleAssignments/Member/Title,ListItemAllFields/RoleAssignments/Member/LoginName,ListItemAllFields/RoleAssignments/Member/Email,ListItemAllFields/RoleAssignments/Member/AadObjectId/NameId,ListItemAllFields/RoleAssignments/Member/Users/PrincipalType,ListItemAllFields/RoleAssignments/Member/Users/Title,ListItemAllFields/RoleAssignments/Member/Users/LoginName,ListItemAllFields/RoleAssignments/Member/Users/Email,ListItemAllFields/RoleAssignments/Member/Users/AadObjectId/NameId&$expand=Author/AadObjectId,ListItemAllFields/RoleAssignments/RoleDefinitionBindings,ListItemAllFields/RoleAssignments/Member/AadObjectId,ListItemAllFields/RoleAssignments/Member/Users/AadObjectId
Query parameters in a readable form:
$select=
Author/Title,
Author/LoginName,
Author/Email,
Author/AadObjectId/NameId,
UniqueId,
Name,
Length,
ServerRelativeUrl,
TimeLastModified,
ListItemAllFields/RoleAssignments/Member/PrincipalType,
ListItemAllFields/RoleAssignments/Member/Title,
ListItemAllFields/RoleAssignments/Member/LoginName,
ListItemAllFields/RoleAssignments/Member/Email,
ListItemAllFields/RoleAssignments/Member/AadObjectId/NameId,
ListItemAllFields/RoleAssignments/Member/Users/PrincipalType,
ListItemAllFields/RoleAssignments/Member/Users/Title,
ListItemAllFields/RoleAssignments/Member/Users/LoginName,
ListItemAllFields/RoleAssignments/Member/Users/Email,
ListItemAllFields/RoleAssignments/Member/Users/AadObjectId/NameId
$expand=
Author/AadObjectId,
ListItemAllFields/RoleAssignments/RoleDefinitionBindings,
ListItemAllFields/RoleAssignments/Member/AadObjectId,
ListItemAllFields/RoleAssignments/Member/Users/AadObjectId
Normally I get a 200 response as expected, with no problem.
When for some files I get a 500 response, the body is the following:
{"error":{"code":"-2146232832, Microsoft.SharePoint.SPException","message":{"lang":"en-US","value":"User cannot be found."}}}
However, If I remove the "Author/AadObjectId" from the $expand list, the request succeeds. Such problems come from both SharePoint sites and OneDrive personal sites. The problem seems to be persistent for the given SharePoint file.
There is a similar case reported on the StackOverflow: How to resolve sharepoint error- 500 Internal Server Error?. This was the same error response, and the suggestion was that the problem might be either with the resource or with the user.
However, in my case, I can see that the actual file Author is a valid and active user, and the file in question is valid and accessible otherwise.
So my only explanation would be a problem with data integrity of some sort on the Microsoft side.
My question is if it's a known issue, and how I can fix my API call.

Google Contacts API 404 photo upload

Using the Contact API v3 I had a working implementation for uploading a photo to an existing contact.
Since a couple of weeks this fails with 404. The implementation has not been changed when the API servers started to sent back 404s and I don't see any indication what exactly changed and would result now in the 404s.
I'm using HTTP PUT + the photo URL of the contact.
One interesting observation I made was that the contact's self-URL changes which each request (the provided details are still always the same and correct).
Did anyone notice something similar ?
Edit: Link to issue: http://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3301&q=contact&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Opened%20Summary
tried different photo formats and sizes, different content types and even photos which had been uploaded previously (when it was still working). Nothing changed the behaviour of returning 404.
w.r.t to change contact ids: the contact ID changes between API invocations. I first thought it could be related to reopened connection( no keep-alive) that contact ids change. However what speaks against this being the cause of the issue is that first retrieving a contact and then editing a contact's address is possible without any issues.
authentication does not seem to be problem as well - otherwise editing a contact's address would not work as well.
PS: I'm using the JSON output format when retrieving the contact.
PS2: s/GET/PUT in step 3 ( I tried to change PUT to GET to see if it still returns 404... which it does).
PS3: am not using any client library but implement the protocol directly (which should not be relevant for the HTTP PUT on the photo link
After hours of investigation I found out that this is particular an issue using OAuth1. Using OAuth2 the exact same photo links which had been returned when requesting a specific contact record using OAuth1 work and return the photo data on HTTP GET. I expect HTTP PUT for photo links using OAuth2 to succeed as well.
Remains open if if there's some kind of workaround for OAuth1.

Rest API Returning HTTP Status Code

I have a scenario where my API application contacts external datasources and for this particular example, my API requests a list of colours from the external datasource. Sometimes the datasource doesnt have these colours and returns a plain text response of "There are no options to display" with a HTTP status code of 200 OK.
What i am wondering is what status code i should return to the client which is consuming my API in this scenario? A 404 not found or 204 no content...? Im not sure what would fit best.
Thanks
Is it valid not to return any colours? In which case your original 200 may be the right status code to use.
204 is normally used to indicate success, but the client need not update any information it holds; deleting or updating a resource for example are valid times to use 204.
404 seems wrong if the same URL is being accessed, in your scenario it sounds like the state of resource may change overtime (and it may be empty), but it always exists.