Fixing HTTP 400 Bad Request Errors in SharePoint REST API

I had subscribers experience HTTP 400 Bad Request errors with SharePoint 2013 REST API. I shared how to troubleshoot the issue on my Pluralsight course.

By Last Updated: June 30, 2014 2 minutes read

File this one away in the “the negative side of building on a service / platform” category. Here’s the deal…

All the sudden I started getting comments from subscribers of my Pluralsight course Building SharePoint Apps as Single Page Apps with AngularJS that they were getting a HTTP status code 400, Bad Request, when they were making HTTP calls using the SharePoint 2013 or SharePoint Online (Office 365) REST API.

That’s strange because everything was working just fine. So I grabbed the exercise files from the course download to make sure I could have the same code they had. At the time I didn’t have a working SharePoint 2013 virtual machine to test against so I just used my Office 365 developer site… everything worked just fine. So what gives?

So I dug a bit more and found the people having issues were using SharePoint 2013 Service Pack 1… no updates applied since SP1. When I was able to get to my SP1 development virtual machine, I had the same error. A little more digging and testing and you won’t believe what I found.

According to the OData v3 specification, section 3.1, in order to get a JSON string back you should use the request header ACCEPT with the MIME type value application/json;odata=verbose. If you have multiple values in the ACCEPT, you are supposed to separate them with semi-colons, as the spec shows in the above snippet. But notice how the snippet doesn’t include a trailing semicolon?

With SharePoint 2013 prior to SP1, you could include a trailing ; and everything would work just fine. However SP1 introduced something that would throw an HTTP 400 Bad Request error when you would issue a REST API call. Grrr… can’t find that anywhere in the SP1 release notes!

But it gets better, because apparently someone realized they did this and fixed it because in a cumulative update that shipped since SP1, the pre-SP1 behavior is back so you can include a trailing ; in your ACCEPT header.

Now isn’t that a bit annoying? I guess the safest thing to do is to not use the trailing ; because that way you’ll work in a SharePoint 2013 / SharePoint Online pre-SP1, SP1, and post-SP1 world.

I’m going back to pulling my hair out…

Branded horizontal divider.