Splitting an API between REST and Real Time

Multi tool use
Multi tool use












0















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?










share|improve this question























  • 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


















0















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?










share|improve this question























  • 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
















0












0








0








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?










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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





















  • 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














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
});


}
});














draft saved

draft discarded


















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
















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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
TRztv3z,ZYlF QbxQFW425tNhup ziPXcO5,IOIKbqFl1W

Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas