REST API - Yet Another UI

#discuss

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.

Top comments (12)

Kasey Speakman • Jul 9 '18 • Edited

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 }

Dávid Szabó • Jul 9 '18

"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.

Kasey Speakman • Jul 9 '18

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. :)

Dávid Szabó • Jul 9 '18

Exactly! :D

Maximilian Torggler • Jul 9 '18

That's exactly what GraphQL is about.

Dávid Szabó • Jul 9 '18

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.

Maximilian Torggler • Jul 9 '18

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.