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
- Give details about a particular coffee or sandwich served.
- Save the orders, make changes in them or remove the entries.
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
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).
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.
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.
- Change the code on the server
- Save the changes and deploy the changes on the server and wait.
- Test if the API is sending out the just the right information
- 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:
- Unzip and add values to a config file and ready to go, as opposed to installing MVC frameworks (Django, Rails, CodeIgnitor, CakePHP, Slim, Laravel, Zend, Yii).
API Development Approach
- REST resource-oriented approach makes it easy to design and create the APIs as there is no need to design and maintain complex routing architecture using code. Metamug forces the developer to use the correct REST standards.
- Uses XML files for defining REST resources which allows "Hot Deployment" of APIs and changes can be reflected quickly (change your API in 200ms).
- Encourages use of PL/SQL which is fast and easy to use (The 4th gen lang).
- Developers end up using pure SQL inside MVC anyways as ORMs provided by MVCs are not efficient.
- Lack of need of writing API development code coupled with writing data-processing logic in PL/SQL makes the system, very fast as compared to using MVC frameworks (whose code creates a large overhead, Python/PHP are already slow, the MVC frameworks have their own ORMs (even slower!!!)).
- The entire framework runs on Java making the overhead of the framework code very less, as Java intermediate code runs a lot faster than any other language except C/C++.
- Provides containers (processable interfaces) where Java code can be directly written without the fuss of installing and configuring Java environments.
- Maven support allows the user to access the vast range of Java libraries, so there's nothing that the system cannot execute (Java has the largest number of libraries available If you can do it in some language bet you can do it in Java!).
Minimalism saves time
- Metamug handles all the common tasks (creation of API endpoints, request parameter validation, processable interfaces) for you. (Don't repeat yourself). This as opposed to installing MVC frameworks and then writing all the code inside the boilerplate provided by the framework itself (then why use the MVC framework in the first place?).
- Focus on your data and client-side UI, leave the rest (pun intended) to us.
API Doc Generation
- Metamug will automatically generate API docs, no need to search elsewhere. You don't need any swag here. We keep it clean and more simple. Your pointy-haired boss can also read the API doc.
- No need to use 3rd party API analysis tools. Metamug tells you how your REST API is being called from the apps. Check the homepage
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.
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.