Blog

You Give REST a Bad Name from r/javascript

REST has proven itself.

REST is same technology browsers use to talk to servers. You can easily find the code in every programming language to make an HTTP call. Building a REST client is easier compared to rolling out your own implementation. It's simple to understand and scalable since sessions and cookies are not needed. Just because of its a standard, the app knows what is expected by the server and what it can expect in return.

Its all about that Resource

The resource can be any real-world object. Let's say I have a coffee shop and I serve coffees and sandwiches. And I decide to make an app to take orders for them. So I will build a REST API to ask the server to

Now let's say a customer orders both coffee and sandwich together. I can further think of "order" as an object, a real-world entity. That's exactly what a resource is.

According to me, identifying proper resources (coffee, order, sandwich etc.) is what makes a good REST API design.

The Resource Identifier

In REST, each coffee or sandwich will have an identifier. Likewise, each order will have an identifier. Whenever you are talking to a REST API, you are asking for a resource. If you are asking for a particular resource, you need to specify an id with your call to that resource.

"Give me the information about the coffee served in order number 32" looks like

/order/32/coffee

Now, if 3 coffees were served in order #32. REST API SHOULD give you information about all 3 coffees served. But, I need information only about the coffee #256. So, I will specify the id of coffee (256) served in that order (32).

/order/32/coffee/256

Changing the order number (e.g. /order/64/coffee/128 ) should tell me about a coffee served in another order. With this example, we understand that objects can contain another object. The order contains coffee. An Order contains sandwiches. But coffee doesn't contain sandwich or vice-versa.

/coffee/32/sandwich/256

So the REST API will give some error response if above is asked. If it's nice, it can tell you coffee doesn't contain sandwiches.

What happens behind the REST API?

Developers take the request for a resource and understand what the app wants to do with that resource. In the background, they do operations on the database or run some code. They handle all the errors. Perform checks on data sent in the request.

Stateless is REST's middle name.

So the developer has to keep everything in the database or somewhere else. REST won't keep anything with itself. It doesn't even remember the last resource you asked for. This frees the developer from managing sessions and it acts like the old apache server only to serve resources.

Rest API Backend for your next Project

If you are building an app or thinking of building on in the future. The most important things you need is a backend. The backend that stores your data and talks to your app. Getting it right is critical. If you don't. You will end up spending most of your time getting it right.

If you have already built an app or two. You already know the cycle. The cycle to make even the smallest change.

  1. Change the code on the server
  2. Save the changes and deploy the changes on the server and wait.
  3. Test if the API is sending out the just the right information
  4. Test the App for WYSIWYG

What If I told you. There's an App on the market.

What If I told you. There's an App on the market. No, it's right here. And it's called Metamug. It focuses is on building the product faster, more reliable, dynamic, high performance and secure.


Setting up and installing metamug server:

API Development Approach

Performance

Business Logic

Minimalism saves time

API Doc Generation

Analytics

Why metamug won't let you define URI?

Mapping path to a function

There are many libraries out there, which maps a function to the path. REST is designed to use URI as the resource identifier, as the name suggests. According to REST, each URI should represent a unique resource. This resource should be considered an object.

Using path as verbs

Developers often name the URI (in systems they are allowed to) according to the function being performed. For, example /api/users/getUserData is created inside the resource and mapped to a function that is supposed to retrieve user data. Now as the application grows, such URLs grow in number and there is no structure to manage it and it becomes cumbersome.

Imperative or declarative URI

Metamug API server doesn't allow the developers to define the URL. The user is not even allowed to add the version number in the URI. The resource file, its version, and backend are together used to form the URI. This makes sense since this comes with consistency and a structured approach for building scalable APIs.

As soon as a resource file is deleted the resource is unavailable. So the developer is not declaring the URL at any point the system. Thus, relieving him from managing it.

Resource Nesting

Now, as the developer starts to follow this imperative approach. He can now visualize the resources as a group of objects that can be related as well to retrieve some information. Hence, resource nesting is born. Resource nesting allows the developers to connect two or more resources with (HAS-A) relationship. Identifying these relationships can greatly ease the development. Here's an example.


Share Tweet Share