Have you ever used an API that returned an HTML error page rather than the JSON you anticipated, making your code to blow up? What about getting a 200 OK status code with a cryptic error message in your response? Building an API can be rapid. Frameworks like Express, Flask, and Sinatra combined with Heroku or zeit’s presently help any developer have an API up and running in a few minutes.
In any case, building a genuinely secure, strong, API can take somewhat more work. You need incredible docs, clear and compact error messages, and to meet developers’ desires of how your API should function. On the opposite side, we have developers interacting with these APIs. What’s more, we, as developers, sometimes make mistakes. We can make false assumptions about how an endpoint should function, not read the docs firmly enough. That is where Runscope comes in.
Working with thousands of developers to solve their API issues has given us one of a kind knowledge into issues they regularly observe when integrating and interacting with APIs. Here is a list of 6 normal mistakes that can find you guard, why they occur, and how you can avoid them.
Most common API mistakes and how to avoid them?
1. Using http:// Instead of https:// –
Forgetting a single “s” can get you in a difficult situation when testing an API. Some APIs may not only support HTTPS, while others may support HTTP for some endpoints and not others. Even when an API supports both, you may run into some errors. For instance, some APIs redirect HTTP traffic to their HTTPS counterpart, yet not all frameworks will be configured to follow a 302 status code. Node.js request module, for instance, will follow GET redirects by default, but you need to explicitly set followAllRedirects to true if you need to follow redirects to POST and different methods.
APIs may also stop supporting HTTP, so it’s essential to stay up to date with any changes. Great API providers will allow users previously by means of email and any social media channels they have. Another step you can take is to use a tool like Hitch, which allow you to follow certain APIs and be notified in the event that anything changes.
If you’re asking yourself if your API should support HTTPS, at that point the appropriate response is yes. The process for getting certificates used to be an issue, however with solutions like Let’s Encrypt and Cloudflare, there’s no reason to not support HTTPS. In case you’re unsure why you ought to do it, or don’t think you should because you’re not transmitting any delicate data,
2. Unexpected Error Codes-
A decent API error message will allow developers to rapidly discover why, and how, they can fix a failed call. A terrible API error message will cause a high number of support tickets and wasted time.
In this issue, a code grant flow would return an error message saying that the request was invalid, but it wouldn’t give further details. Great usage of HTTP status code and clear error messages may not be too good, however it tends to be the difference between a developer evangelizing your API.
Steve Marx had this to state in “What number of HTTP status codes should your API use?”: “…developers will have a simpler time learning and understanding an API in the event that it follows the same conventions as other APIs they’re comfortable with.” As an API provider, you don’t need to implement 70+ diverse status codes. Another extraordinary advice by is:
Twilio is an extraordinary case of best practices for status code and error messages. They go the additional mile and include links in their responses, so the error message is compact while still providing the developer with more data on the off chance that they need it.
3. Using the Wrong HTTP Method-
This is a simple one, however surprisingly common. Many times this can be accused on poor documentation. Possibly the endpoints don’t explicitly say what methods are supported between GET/POST/PUT and so forth., or they have the wrong verb.
Tools can also play tricks on you in case you’re not cautious. For instance, suppose you need to make a GET request with a request-body (not an incredible practice, however it occurs). On the off chance that you make a curl request using the – d option, and don’t utilize the – XGET flag, it will consequently default to POST and include the Content-Type: application/x-www-form-urlencoded header.
This post by Daniel Stenberg (author and maintainer of curl) on the unnecessary use of curl- X also illustrates another possibility you may run into this issue when dealing with redirects:
Different times, we may fall into past assumptions and simply use an inappropriate method. For instance, the Runscope API uses POST while making new resources, for example, test steps or environments, and PUT while modifying them. However, Stripe’s API uses POST methods when creating and updating objects.
The two approaches are valid, and Stormpath has an extraordinary blog post discussing about their differences, and how to deal with them as an API provider. Regardless of which one you pick, simply be consistent all through your API and make sure to have correct and up-to-date docs, so your users don’t run into this error.
4. Sending Invalid Authorization Credentials-
APIs that implement OAuth 2, for example, PayPal, normally require the developer to incorporate an Authorization header for each request. It is common to confuse that with Authentication rather, so if your request is falling, ensure you’re utilizing the right word.
Another issue that springs up with Authorization headers is actually constructing it correctly. OAuth 2 tokens should be prepended with “Bearer” for them to work:
Authorization: Bearer your_api_token
It’s also significant when using HTTP Basic authentication to pay close attention to the syntax of the header value. The structure is as per the following:
Authorization: Basic base64_encode(username:password)
Common mistakes incorporate forgetting the Basic (note the space) prefix, not encoding the username and password or forgetting the colon between them. On the off chance that an API provider just requires a username without a password (like Stripe, where your API key is the username), you’ll need that pesky colon after the username, regardless of whether there’s no password.
5. Not Specifying Content- Type or Accept Header-
Accept and Content- Type headers negotiate the type of data that will be sent or received between a client and server. Some APIs will accept requests that don’t contain any of those headers, and simply default to a common format like JSON or XML.
Different APIs are somewhat more strict. Some may return a 403 error in case you’re not explicit about the Accept header value and require you to incorporate those headers on requests. That way, the server knows what data the client is sending, and also what format they hope to receive in return.
This issue can also because some confusion on the off chance that you are testing your API with various tools. curl, for instance, alongside other well known testing tools, will automatically include an Accept header for any MIME type: */* with each request. We, at Runscope, don’t include a default Accept header, so this can get you various outcomes when testing a similar endpoint.
6. APIs Returning Invalid Content Types When There Is an Error-
On the off chance that you forget to send an Accept header with your request, the API can’t be sure what response format you’re expecting. For API providers, some frameworks and web servers default to HTML. For instance, Symfony, a PHP framework, defaults to returning a 500 HTML error. Thus, in case you’re making an API that has no business returning HTML, make sure to check the defaults error response.
Another explanation this may happen might not have to do with your API, however with the routing mesh or load balancer that sits before your API. For instance, on the off chance that you have a Nginx instance fronting your API and it experiences a request timeout or other error, it might return an HTML error before your API instances even get an opportunity to know what’s happening.
Writing the appropriate API plays important role in web development processes. But some common mistakes with API can lead to the failure of a task. These are most common API mistakes. This list can also include few others. You can easily avoid these mistakes with the solution as given above.
Are you facing difficulty for writing the appropriate API? Consult with solace experts to get the best solution. Team will surely help you through their expert’s knowledge. Solace experts are well trained in new trends for web development to give you the best solution.