2

I have a background on .NET development, recently I was asked to code back-end service for a mobile app. I had experiences on MVC, and now I'm trying to understand more on Restful Web API.

My questions are: Is Restful API as back-end service one of the best (or suitable) choice for mobile app? What is the common solution for mobile app back-end service nowadays?

Edit: (about off-topic)

I read this before I ask this question.

If it's related to higher level programming concepts or is conceptual (but still related to programming), it should be on Programmers.

This is not a question about recommend a tool, library or favorite off-site resource

I asked about

  • if restful web API suitable for creating mobile service
  • what are the common solutions to build mobile app API

closed as off-topic by jwenting, Kilian Foth, GlenH7, user40980, Bart van Ingen Schenau Aug 29 '14 at 18:28

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – jwenting, Kilian Foth, GlenH7, Community
If this question can be reworded to fit the rules in the help center, please edit the question.

  • It's a great choice, yes. – Rowan Freeman Aug 28 '14 at 4:55
  • tool, product or service recommendations are explicitly off-topic per help center. See meta.programmers.stackexchange.com/questions/6483/… – gnat Aug 28 '14 at 7:50
  • We did this in our last project and so far everybody is happy with it. Developers easily get how the API works and is structured, most common tasks fir very well into the REST structure. (@gnat I don't see where he is asking for tools or services to be recommended. May still be off topic as opinion based, but basically it's a question about API architecture). – thorsten müller Aug 28 '14 at 7:53
  • @thorstenmüller thanks for catching this. Your reasoning makes sense, I retracted close vote – gnat Aug 28 '14 at 8:39
  • 1
    @gnat I think your edit doesn't reflect what am I trying to ask, that's why I rolled-back. – Timeless Aug 28 '14 at 9:10
0

In my humble opinion the answer is both Yes and No.

My current work experiences are dealing with a JavaScript front end (using ExtJS & Sencha Touch) and all my data connections are to a .Net Web API 2.0 RESTful back-end. But my application is internal and so I do not have as much concerns for Security and Authentication & State, plus I am hosting these small tidbit components within SharePoint (God forbid!!) and they are compartmentalized. So a Web API 2.0 RESTful back-end for my CRUD works fantastically!

But I can totally see David Scholefield's points also. You are asking a very broad apples to Oranges to Kitchen Sink kind of question. In the end you want to do some deep dive Requirements gathering and compare the needs and Pros & cons, because as everyone knows, every project is slightly different.

-1

No. In my experience RESTful APIs and mobile apps aren't a natural fit.

Although there are a number of different views of what 'RESTful' actually means, one of the common themes throughout most people's view of RESTful is that the API should be stateless between calls. This is perhaps one of the few, agreed, defining features.

However, mobile apps are very prone to communications issues (think 3G flakey connections), and apart from endless retries of complete call/response messages, the only way to deal with this for efficient large data responses is to allow for partial responses and some kind of additional protocol implemented in the API to allow for partial results in chunks or blocks. This is especially true for APIs that have to synchronise large data sets. This isn't possible in a stateless, pure, RESTful API message structure.

Pure RESTful API message definitions wouldn't allow messages from the client like 'OK, I got the first 10K of data but i didn't get the whole response, can you send the remaining bit...'

So, implement a suitable message API between mobile client and server, but don't be a slave to 'RESTful' definitions or you'll be sacrificing good design for trendy techniques.

  • the way to fix unreliable communication systems is to use a stateless design. Managing a large data set is an issue for any comms system, but you can handle it perfectly well in a stateless REST system, at the very least chunk the data and send it as chunks (a'la bittorrent) where the client can respond "ok, I got chunks 1, 2 and 4, but 2 failed its CRC, resend 2 and 3 please". You should be caching large data locally anyway, even in a stateful comms system, transferring all that data repeatedly is a bad design. – gbjbaanb Aug 29 '14 at 9:18
  • Yes, this is precisely what I mean - but the server side recording chunks for failed transmission means it isn't stateless - it is maintaining state for each connecting client (which chunks have successfully been received and which not). You then have local functions for flushing stale chunks, dealing with late requests for flushed chunks etc. Many people would describe this is stateful and therefore not pure RESTful API implementation. So some kind of hybrid is usually needed. – David Scholefield Aug 29 '14 at 13:16
  • but the server doesn't need to record chunks. Admittedly it has to be able to reproduce the data required for transmission. The client will ask for what it needs, the server forgets the client after each response. (it might cache the data for a while because you expect further requests, but that isn't "holding state"). – gbjbaanb Aug 29 '14 at 13:48
  • If the data being requested is changing, then it needs to hold chunks on the server because the chunk number isn't enough for the server to know what the state was at the time of request. Consider a shopping app that downloads a local copy of a product list for offline use - the server needs to download a lot of product data and chunks it. It needs to know what chunk of that particular data set it sent to that client so the client gets a consistent set because its product data may be changing all the time. I know, I've programmed just such a system and it has to be stateful per client. – David Scholefield Aug 29 '14 at 14:07
  • That's only if the data is changing. In such cases, you either need to be stateful, or send the whole lot in one go. For a product list, there's no reason the client couldn't request the list and then request each product individually (maybe as the user views a product) – gbjbaanb Aug 29 '14 at 14:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.