Splitting an API between REST and Real Time

Multi tool use
We are designing a web application. This application is a collaborative editor of complex documents. We will use some sort of Real Time framework (either SignalR or socket.io, for the purpose of this question let's assume we'll use SignalR).
We have two options. First - make the entire API a SignalR API - everything goes through Hubs, from login to simple queries to updates to long queries. The second option is splitting between SignalR and REST - logins, updates and one-time queries are RESTful, long running queries are SignalR.
We are not concerned with additional clients to the system, other than our own frontend.
So far we can't find a real reason to keep a REST interface, other than "it feels like the right thing to do". Is there any reason to split the API between SignalR and REST, instead of just keeping everything in SignalR?
api socket.io signalr
add a comment |
We are designing a web application. This application is a collaborative editor of complex documents. We will use some sort of Real Time framework (either SignalR or socket.io, for the purpose of this question let's assume we'll use SignalR).
We have two options. First - make the entire API a SignalR API - everything goes through Hubs, from login to simple queries to updates to long queries. The second option is splitting between SignalR and REST - logins, updates and one-time queries are RESTful, long running queries are SignalR.
We are not concerned with additional clients to the system, other than our own frontend.
So far we can't find a real reason to keep a REST interface, other than "it feels like the right thing to do". Is there any reason to split the API between SignalR and REST, instead of just keeping everything in SignalR?
api socket.io signalr
REST describes the whole interaction model (or architecture to be more precise) of an application not only a HTTP endpoint. It should be used if you want to have freedom on the serverside to change URIs or what not without breaking clients. If you don't need such properties, simply don't go for such. What works for the Web usually also works without any further issues for REST as it is just a generalization of the former.
– Roman Vottner
Jan 1 at 7:50
add a comment |
We are designing a web application. This application is a collaborative editor of complex documents. We will use some sort of Real Time framework (either SignalR or socket.io, for the purpose of this question let's assume we'll use SignalR).
We have two options. First - make the entire API a SignalR API - everything goes through Hubs, from login to simple queries to updates to long queries. The second option is splitting between SignalR and REST - logins, updates and one-time queries are RESTful, long running queries are SignalR.
We are not concerned with additional clients to the system, other than our own frontend.
So far we can't find a real reason to keep a REST interface, other than "it feels like the right thing to do". Is there any reason to split the API between SignalR and REST, instead of just keeping everything in SignalR?
api socket.io signalr
We are designing a web application. This application is a collaborative editor of complex documents. We will use some sort of Real Time framework (either SignalR or socket.io, for the purpose of this question let's assume we'll use SignalR).
We have two options. First - make the entire API a SignalR API - everything goes through Hubs, from login to simple queries to updates to long queries. The second option is splitting between SignalR and REST - logins, updates and one-time queries are RESTful, long running queries are SignalR.
We are not concerned with additional clients to the system, other than our own frontend.
So far we can't find a real reason to keep a REST interface, other than "it feels like the right thing to do". Is there any reason to split the API between SignalR and REST, instead of just keeping everything in SignalR?
api socket.io signalr
api socket.io signalr
asked Jan 1 at 7:07
zmbqzmbq
29.3k962124
29.3k962124
REST describes the whole interaction model (or architecture to be more precise) of an application not only a HTTP endpoint. It should be used if you want to have freedom on the serverside to change URIs or what not without breaking clients. If you don't need such properties, simply don't go for such. What works for the Web usually also works without any further issues for REST as it is just a generalization of the former.
– Roman Vottner
Jan 1 at 7:50
add a comment |
REST describes the whole interaction model (or architecture to be more precise) of an application not only a HTTP endpoint. It should be used if you want to have freedom on the serverside to change URIs or what not without breaking clients. If you don't need such properties, simply don't go for such. What works for the Web usually also works without any further issues for REST as it is just a generalization of the former.
– Roman Vottner
Jan 1 at 7:50
REST describes the whole interaction model (or architecture to be more precise) of an application not only a HTTP endpoint. It should be used if you want to have freedom on the serverside to change URIs or what not without breaking clients. If you don't need such properties, simply don't go for such. What works for the Web usually also works without any further issues for REST as it is just a generalization of the former.
– Roman Vottner
Jan 1 at 7:50
REST describes the whole interaction model (or architecture to be more precise) of an application not only a HTTP endpoint. It should be used if you want to have freedom on the serverside to change URIs or what not without breaking clients. If you don't need such properties, simply don't go for such. What works for the Web usually also works without any further issues for REST as it is just a generalization of the former.
– Roman Vottner
Jan 1 at 7:50
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53993668%2fsplitting-an-api-between-rest-and-real-time%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53993668%2fsplitting-an-api-between-rest-and-real-time%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
kNq4EEa 1 I,Ucrl,Z0RdfCSwJ7f6X OLNpnPe c,zK uDweyTUo93NF kwYjsKM2wqv0KO I8fy7JWhjM,vvsK,fm1p0HQamj,dPR c
REST describes the whole interaction model (or architecture to be more precise) of an application not only a HTTP endpoint. It should be used if you want to have freedom on the serverside to change URIs or what not without breaking clients. If you don't need such properties, simply don't go for such. What works for the Web usually also works without any further issues for REST as it is just a generalization of the former.
– Roman Vottner
Jan 1 at 7:50