5 Basic REST API Design Guidelines

In this simple and straightforward guide of “5 Basic REST API Design Guidelines” . This guide shows 5 basic design guidelines that make a RESTful API robust and strong, it is key factor for API success. Each REST API design are different depend on what are the principles it for. The 5 basic design guidelines that make a RESTful API are Resources (URIs), HTTP methods, HTTP headers, Query parameters, Status Codes.

First is Resources (URIs), although we think naming is easy, but every have rule and constant. REST API unlike we use action verbs for other computer coding, RESTful use concrete names. URI case is naming resources in a program, there are 3 main types of case conventions. CamelCase has been popularized by the Java language, the main drawback is to be ineffective in contexts which are not case sensitive. snake_case has been widely used for years by C programmers, and more recently in Ruby. spinal-case is a variant of snake case which uses hyphens “-” to separate words. URLs are “case sensitive”, because of this reason it is recommended to use spinal-case.

One of the key objectives of the REST approach is using HTTP methods as an application protocol in order to avoid shaping a homemade API. use HTTP verbs to describe what actions are performed on the resources and facilitate the developer’s work handling recurrent CRUD operations. There are 4 main methods: the GET method is used to retrieve information from the given server using a given URI, a POST request is used to send data to the server, PUT method is to replaces all current representations of the target resource with the uploaded content, and DELETE is to removes all current representations of the target resource given by a URI.

HTTP header fields provide required information about the request or response, or about the object sent in the message body and query parameters which have 4 types paging, filtering, sorting and search.

Last is status codes, it is very important that make use of the proper HTTP. There are a lot of status codes, but the common use such as 200 – Everything worked, 404 – NOT FOUND – There is no resource behind the URI…

Resource modeling requires a careful consideration based on the business needs, technical considerations and cost-benefit. I thought this guide are simple and easy to follow. REST API should be simple and work as it intended to.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s