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)
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)
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.
Latest comments (12)
Yes, I like that :D
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.
Because the verbs are limited in REST, you will eventually have to expose the real request in the URL or headers anyway.
"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.
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. :)
Exactly! :D
API != UI in my opinion, a user hardly interacts writing HTTP headers and and Json-formatted POST bodies...
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 :)
KISS
Yes :)
That's why I think anything that is consumable is considered as a "UI".
That's exactly what GraphQL is about.
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.
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.