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