Rules to Better Web API

Want to build a Web Application or API? Check SSW's Web Application / API consulting page.

  1. REST is well established and most developers choose it by default when starting a new project. But now we have a choice and, depdending on your requirements, there may be a better option.

  2. When consuming APIs in your applications, you need to make HTTP requests and handle responses. You have several options for generating API clients, ranging from manual implementation to automated code generation from OpenAPI specifications.

  3. GraphQL is a query language for your APIs. It lets you expose a schema, which is a combination of types, queries, and mutations and your client applications can define their own queries based on that schema. You can think of it as SQL for the web.

    GraphQL was developed by Facebook in 2012 to solve a problem with their mobile app, which was chewing users' data and battery and leading to negative reviews. This is because the Facebook newsfeed combines data from many entities and data sources, which required multiple API calls. GraphQL allowed them to retrieve all the data they need with 1 call.

  4. Good error design is as important to the success of an API as the API design itself. A good error message provides context and visibility on how to troubleshoot and resolve issues at critical times.

  5. The use of correct response codes is a simple yet crucial step towards building a better WebAPI. In ASP.NET Core, by default the WebAPI framework sets the response status code to 200 (OK), regardless of whether the task succeed or an error occurred.

    You can save yourself countless hours of painful debugging , by specifying the correct response code.

  6. Client-side validation provides a great user experience but this must always be backed up by server-side validation.

per page
1 - 6 of 6 items
We open source.Loving SSW Rules? Star us on GitHub. Star