DEV Community 👩‍💻👨‍💻

Dávid Szabó
Dávid Szabó

Posted on

REST API - Yet Another UI

I'm working on my new product and it's my task to develop the backend.
It's not a complicated tech stack, we are going only with a few pieces for an MVP:

MongoDB <-> Node.js <-> React Native (Android & iOS)
Enter fullscreen mode Exit fullscreen mode

It's been a while since I've worked on a not small project. I'm trying to decouple the Service Layer from the "Web Service (Layer)" (REST API), and I just realized something:

REST API is just a UI

This might be a bit silly or bold statement, but if you think about it then it makes sense in my opinion. When I realized that, the tech stack changed:

MongoDB <-> Core (Node.js) <-> REST API (Node.js) <-> React Native (Android & iOS)
Enter fullscreen mode Exit fullscreen mode

All of these pieces are decoupled.
I might be stupid, but this is a serious realization for me.


I just wanted to share this with you guys and would like to hear what you think.
We never stop learning and hopefully you will write something that will make me realize something very important.

Top comments (13)

Collapse
 
kspeakman profile image
Kasey Speakman • Edited on

I'm afraid I didn't quite follow your point.

In my thinking, UIs and APIs are both kinds of programs. They might even have common underpinnings, but their purposes are very different. UIs are about assisting the user, turning their inputs into requests on the system. The API is about validating / executing requests and sending the resulting changes to external systems (db, email, files, other APIs, etc).

If you are using a REST API as just another UI, that seems like an unnecessary abstraction. This is why I tend to do requests as messages rather than following REST strictly. I don't see a lot of benefit from another layer of abstraction versus transmitting exactly the request I need. E.g.

# this requires interpretation as updating user preferences
PUT /user/1234/preferences { ... }

# this is very explicitly requesting to update user preferences
POST /command/UpdateUserPreferences { userId : 1234, ... }

Because the verbs are limited in REST, you will eventually have to expose the real request in the URL or headers anyway.

# there is no MERGE verb, so it becomes part of the URL
DELETE /user/2345/merge/1234

# but to me this is still a lot more clean
POST /command/MergeUsers { userId: 1234, redundantUserId: 2345 }
Collapse
 
davidszabo97 profile image
Dávid Szabó

"If you are using a REST API as just another UI, that seems like an unnecessary abstraction."
It's not really an unnecessary abstraction. How would you expose your service to the public? If you think it's an unnecessary abstraction, then anything that exposes your service to the public is unnecessary. It might be a SOAP, XML-RPC or whatever you prefer. But it's just one way to expose your service.

I am not a strict REST API follower, your examples make sense.

Collapse
 
kspeakman profile image
Kasey Speakman

Ah gotcha. It wasn't clear to me that it would be a public API. Yes, public API needs to be a separate thing from the internal API. The concerns are different. I suppose you could look at it as a user interface, but your users are other developers. :)

Thread Thread
 
davidszabo97 profile image
Dávid Szabó

Exactly! :D

Collapse
 
scriptify profile image
Maximilian Torggler

That's exactly what GraphQL is about.

Collapse
 
davidszabo97 profile image
Dávid Szabó

You mean GraphQL is just another UI? :)
Right now I think anything that spits out data that another application can read, that's a UI / View or whatever you call it.
Maybe I played too much on the front-end side and totally messed up my thinking that's why I thought that REST API is the backend, whereas it is just a presenter and the core/system/business logic is the backend.

GraphQL is cool, but that adds too much unnecessary complexity to my product.

Collapse
 
scriptify profile image
Maximilian Torggler

Ok maybe I missed the original intention of this post. Yea, in that way, GraphQL would also be like "another UI", cause, if the application is architectured in the right way, it can just use the "core" functionality (how you named it here) of the application. Same as REST.

Collapse
 
davidszabo97 profile image
Dávid Szabó

Yes, I like that :D

Collapse
 
mteheran profile image
Miguel Teheran

KISS

Collapse
 
davidszabo97 profile image
Dávid Szabó

Yes :)
That's why I think anything that is consumable is considered as a "UI".

Collapse
 
npeete profile image
Péter Novák

API != UI in my opinion, a user hardly interacts writing HTTP headers and and Json-formatted POST bodies...

Collapse
 
davidszabo97 profile image
Dávid Szabó

Yes! That makes sense, though both of them are kind of an interface. But API is for developers and UI is for actual users.

But if you aren't going too deeply into that, you might realize there is no real difference between them. The user may use the REST API, who knows :)

See this comment

Rest API is "UI",but for the machines, that is how different applications via http methods.

I have found a Quora answer which makes a lot of sense

After all, BOTH are an Interface

PS. Jó látni más magyarokat itt Dev.to-n :)

12 Gorgeous UI Components for Your Design Inspiration

12 Gorgeous UI components for your design inspiration: cards, text, buttons, checkboxes, icons, loaders and menus.