Choosing a proper framework to the server side webservice

[antonio caipora]

Hello!
I'm writing a Android app and every time someone install it the app must connect to a web server to get a updated data that it needs to work properly. It does that only one time and after that is good to go on his own. Is a really small information, 1mb at top. But considering a lot of installation(hopefully) I was wondering what is the best framework to do that(handle a lot of connection even if is to get a small data). What's your opinion?

Since this app is written in Java I was thinking about doing the "server side" part a RESTful service with Springboot but I don't know if it can handle a lot of simultaneous connections. And I don't think I'll need to implement "POST", "DELETE", "PUT". I just need(as far as I can see) to implement "GET". That's why I'm not sure if REST service is good idea. What do you people think?

[Stephan van Hulst]

I don't see why you wouldn't be able to use REST even if it's just one endpoint. REST doesn't say anything about the size of the API. It's just a set of design rules.

Anyway, it really doesn't matter. Do what you're comfortable with. I would use JAX-RS with Tomcat, because that's what I like and can set up quickly. If you like Spring, use that. You wouldn't even need Java, you could even use PHP if that's what makes you happy.

As long as you use proper application design, how much requests your service can handle is mostly just a matter of hardware and configuration, not which framework you're using.

[Tim Holloway]

ReST is actually designed to better handle many, many requests. Unlike session-based web protocols, you don't tied up server storage and you can make the system elastic, because you are likewise not bound to a single server instance - you can have a whole battery of them and randomly load-balance each individual request.

I probably should note that unlike time-sharing services, HTTP does NOT employ long-term connections from client to server and server to client. Instead, each request/response is a separate connect/disconnect. That avoids a lot of network overhead plus since the server will only have a limited number of reply ports it can allocate, it allows recycling them.

The choice of framework is up to you. Often, when I need a simple web services server and security and scalability are not an issue, I use NodeJS. PHP is an old favorite, of course. My mobile devices have the Joplin note manager app installed and they keep each other in sync via an Apache-based WebDAV server. Then there's Java, both serving deployable webapps and Spring Boot webapps in containers. As so on.

[antonio caipora]

Ok thanks for your answer. I have another question about the same subject.

Considering I'll do the server side part a RESTFull service, what can Ido to ensure the server answer only my Android app? I'm asking this because anyone who knows the correct url for the GET request can make this requisition, but I want the server answer only my app.

[Tim Holloway]

More importantly, when the server answers, it answers "No".

In other words, you have 2 options. One is to set up a firewall so that only clients from allowed IP addresses can talk to the host machine on the webapp's port number.

The other option allows general access. For that you need some sort of security tokens. For example userid/password or client-side server security certificate.