Website to App optimization

I have no idea what this is called, but I am currently creating an android app to basically make my site more convenient to access from a phone. It isn't like how a site has a mobile version but I am talking more like how Reddit has an android app and it is easier to do things there. Or just like how facebook has an app. Or just like how MPGH has an MPGH app. You know what I mean? How would I go about doing this or what is it called so I can do some reading on the issue? Thanks.

You access the site through either the same means of login that it uses in a browser or a backend API. Through that you create the layout manually on the app yourself to look how you want on the phone. Each chunk of data can be either parsed from the site itself, or obtained through an API. I can tell you that things like Twitter, Facebook, etc. all use an API. MPGH, I'm not sure.

Oh, so it's basically just parsing and then dealing and displaying the data accordingly? That seems incredibly tedious

Originally Posted by 258456

Oh, so it's basically just parsing and then dealing and displaying the data accordingly? That seems incredibly tedious

Which is why you should build a backend API for your site for the app to use.

How would I go about building an API for my site? I have done similar things in the past like this in php but it was only to transfer words and database entries. Thanks for your fast responses btw.

Create various REST calls or a type of SOAP interface for your application to make requests to. Such as things like:

Code:

string Login( string userName, string password ); // Returns a session token for the logged in user if valid.

Then your application can connect to the API depending on the type. Such as if it is REST formatted:
yourwebsi

re.com/login/USERNAME_HERE/PASSWORD_HERE

Or if it was SOAP, you'd use POST data and send the name/pass that way.

Then you can add other calls such as, obtaining a list of categories and sections on the site:

Code:

string[] GetSectionList( string sessionToken );

Which would require a valid session token returned from the Login call to work etc. And so on.

Originally Posted by atom0s

Create various REST calls or a type of SOAP interface for your application to make requests to. Such as things like:

Code:

string Login( string userName, string password ); // Returns a session token for the logged in user if valid.

Then your application can connect to the API depending on the type. Such as if it is REST formatted:
yourwebsi

re.com/login/USERNAME_HERE/PASSWORD_HERE

Or if it was SOAP, you'd use POST data and send the name/pass that way.

Then you can add other calls such as, obtaining a list of categories and sections on the site:

Code:

string[] GetSectionList( string sessionToken );

Which would require a valid session token returned from the Login call to work etc. And so on.

The first example isn't really an example of a REST route (sorry to nitpick). You'd never, ever expose a password as part of a route. More likely you'd have something like the following:

Code:

http://example.com/api/login

and you would POST (via HTTPS if available) the username and password to that resource to obtain some sort of authentication token (how that happens is implementation dependent; oAuth or whatever).

Only in drastic circumstances (i.e no direct access to your own database from the API server...for whatever reason) would you ever need to parse pre-rendered (i.e from your sites pages) HTML to get back your data. Ideally your API should have at least CRUD access to the database (or some subset of that).

In a perfect world, you would have already built your site according to some nice OOP principals; specifically, mapping your database tables to local structures/classes via either an ORM (if available in your chosen language/framework), or your own handrolled structures which handle the database side of the logic. If this is the case, excellent, you already have 80%+ of your API's gruntwork done. If not, tough titties, you've got some work to do.

When structuring your API, think about what data you're going to need. A good place to start is looking at what sort of resources you'd need to make your entire existing site work properly. If you're exposing a public API that creates a whole new level of complexity as you need to start thinking about what OTHER PEOPLE might want to be able to do with your data. (remembering, of course, that each separate HTTP request is expensive).

For example, consider this poor API design choice:

Code:

Resource #1: Get online users
GET https://example.com/api/users/online
Returns JSON string: '{ "users" : [ 1231141, 456564, 342262, 9048945 ] }'

Resource #2: Get user details
GET https://example.com/api/users/:id/details
Returns JSON string: { "user" : { "first_name" : "Jason", "last_name" : "Bigdick" } }

Now say you wanted to display all the online users to the person currently using the app. The first request gets all the user ids of the people online, however this is useless to the end user. Who remembers all of their friends user id numbers? This means that you need to make a request to Resource #2 for every single online user to get their details separately. For an active site like MPGH this means you'd expect over 300+ requests to Resource #2 at any given time.

There's no "perfect" way to design your API. A lot of applications will let you set fields in the request's query string to specify what kind of information you want to retrieve, others will create overly verbose APIs that return huge quantities of data, most of which is trash. Others create about 5000 different, hard to remember, resources to do every single permutation of a query that you can think of. The best you can do is plan ahead and try to handle it neatly and concisely from the start (or just keep your API private and avoid the whole debacle entirely :P)

The next step would be thinking about how you want to return data to the API user. Some APIs will return pre-rendered HTML as their response, while others return some nice barebones JSON or even XML. The latter is by far my favourite. My view of an API is for it to be an unthinking, security-conscious wrapper around database functionality. As such, it shouldn't try to do anything more; it's up to the user to figure out what they want to do with the data once they get it. For languages like Ruby (via Rails) this can make an API request as simple as:

Code:

 @User = User.find(params[:id])
render :json => @User

Apologies if this just rambled on, it's 2:45am and I'm losing the power of coherent thought

Originally Posted by Jason

[FONT="Tahoma"][COLOR="DimGray"][SIZE="2"]

The first example isn't really an example of a REST route (sorry to nitpick). You'd never, ever expose a password as part of a route. More likely you'd have something like the following:

Code:

http://example.com/api/login

and you would POST (via HTTPS if available) the username and password to that resource to obtain some sort of authentication token (how that happens is implementation dependent; oAuth or whatever).

The first example was in a sentence that was suggesting REST or SOAP. Which just showed a callback to handle the event of a login.

As for REST exposing the password, it is entirely up to the site and REST design to use the password or not in the call. In most cases all auth handling REST calls are handled over HTTPS anyway to help increase security. As well as in some cases, the service expects the password to be encoded in some manner already. (MD5, Base64, etc.)

My post as just for a simple example of what he needs to do to get his end result. Not a tutorial or explanation on the best practices with REST/SOAP interfaces.

Originally Posted by atom0s

The first example was in a sentence that was suggesting REST or SOAP. Which just showed a callback to handle the event of a login.

As for REST exposing the password, it is entirely up to the site and REST design to use the password or not in the call. In most cases all auth handling REST calls are handled over HTTPS anyway to help increase security. As well as in some cases, the service expects the password to be encoded in some manner already. (MD5, Base64, etc.)

My post as just for a simple example of what he needs to do to get his end result. Not a tutorial or explanation on the best practices with REST/SOAP interfaces.

You just posted:

Code:

yourwebsire.com/login/USERNAME_HERE/PASSWORD_HERE

Which isn't RESTful routing at all :/ The only other thing you posted about that I mentioned was your allusion to the need to "parse" content. It seemed like the OP was taking this as a given ("so it's basically just parsing and then dealing and displaying the data accordingly") so I just wanted to clear that up a bit as it certainly isn't the norm.

While some services do ask for a pre-computed hash of the password to be sent rather than the raw value, it's not exactly that great of a way to implement it. A lot of sites (including your own) will probably want to connect with your API on their own website through AJAX (JavaScript). JavaScript has no standard, built-in hashing library, so it really makes it a pain in the ass to use the API when you need to pre-compute a hash value before sending it (proxy pages and shit like that).

@OP - Regardless of all our talk about using a REST API, Unlike Rails, PHP (which it sounds like your using) doesn't just come with a built in RESTful routing scheme. Rails was designed pretty much exclusively around the idea of RESTful design. You might have to investigate some lightweight frameworks or hand-roll your own REST processing if you want to do it in PHP.

Create a REST API with PHP « Gen X Design | Ian Selby

This is a pretty down-to-earth introduction to creating a REST API with PHP (and please note the author's disclaimer about any code posted, it's for learning purposes only)

Thanks so much atoms, u have definitely given me many concepts to read up on. Thanks a bunch

Hmm.... This seems like too much work for what I am trying to do. Not that I am lazy to do it or anything, but I think there might be a different way to do it.

Website to App optimization

Post a Reply

Similar Threads

Tags for this Thread