Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
This is a very general and open-topic question. So yesterday we decided we would like to create an iOS app based off our website that is currently being built with Django. Now, Django, like RoR, is suppose to be transparent to the UI; it shouldn't care what UI the user is using. (Proper MVC).
If I look at some of our code for example, here is how we add an equipment into our system:
#login_required
def add(request):
r_user = request.user.userprofile
form = EquipmentFormAdd(request.POST or None, c_id=r_user.company_id, error_class=DivErrorList)
if form.is_valid():
equipment = form.save(commit=False)
equipment.company_id = r_user.company_id
equipment.added_by_id = request.user.id
default_file_path = EquipmentPicture.get_default_file_path()
url_bucket = r_user.company.s3_bucket.name + default_file_path
cell = form.cleaned_data['cell']
equipment.cell_order = cell.equipment_set.count() + 1
equipment_picture = EquipmentPicture.objects.create(
file=EquipmentPicture.get_default_file_path(),
slug=EquipmentPicture.get_default_slug(),
bucket_name=r_user.company.s3_bucket.name,
bucket=r_user.company.s3_bucket, added_by=request.user,
company=r_user.company, url_with_bucket=url_bucket)
equipment.picture = equipment_picture
equipment.save()
return redirect('equipment_index')
return render(request, 'equipment/add.html', {'equipment_form': form, 'company_id': r_user.company_id})
If I look at this, I see that we are rendering straight-away a template and passing it data. This would't work in iOS.
Few questions:
I see a lot of people creating REST APIs. I don't really see the point of doing that if we can just create HTTPResponses with Django. If we were to use something like TastyPie, we wouldn't be able to just create an equipment (like we do right now) with a POST Statement as if you look at our current add function a lot of stuff is done within that function and TastyPie wouldn't be able to call that.
My main question is should we have a REST API running as well as the normal Django server for both the Web and iOS platform, or just have the same functions, with different entry points and renderings according to it?
When do you create a REST API? A lot of our functions when creating and getting data wouldn't work right now with just standard POST and GET calls. Is that bad?
I am kind of confused... sorry for the long question and thanks again!
A REST API is not something different to GETs and POSTs. It's just using them for data instead of presentation. You output JSON or XML instead of markup code. The API consumer then builds the needed user interface to the data.
The real point of a REST API is to take profit of all the tools that HTTP already offers, instead of inventing another layer of encapsulation (like SOAP)
For instance, to indicate the result (success or not) of some action, use the status code. To indicate an action to perform, typically use the verb (get, post, put, delete, head, options). Other request or response metadata will go into appropriate http headers.
This way data is simpler, caching is easier, and integration is easy as pie.
Also, with a good REST API, you could even build a website that uses some JavaScript framework (eg backbonejs) to build UI from data consumed from the API.
UPDATE
So, given the current status of REST things in Django, and having some experience producing and consuming APIs, I'd tell you to build either:
A RESTful API alongside your web, using the same controllers you use for the website if possible. The same web is in fact RESTful, the only difference is that it is not an API. I have tried in some projects to use several libraries to build an API, but always ended up producing my own code for it. Sometime it's easier that way. All client applications (iOS, android, whatever) will use your API, so you can decouple it completely.
If you don't feel comfortable building all the API by yourself, maybe piston can be a valid alternative to tastypie.
ONLY a RESTful API, and rebuild your site using client-side technologies. Why keeping your (few) servers busy producing HTML, when your (many) customers'/users' browsers can do the same work and you don't pay the electricity bill?
In any case a RESTful API will help you to get the data structure of your application well-organized.
Related
Pretty straight forward question i think. I have created a web app in meteor and its using mongoDB storage. I have UI to update the data in the backend through the web app.
The question then becomes, I have designed an iOS app that i would really love for it to read the data being served to the web app from the mongoDB. As it stands, the app takes a url to a JSON file that i update regularly and serializes it accordingly. I want to pass on the tasks of updating the backend but exposing company employees to the potential mess of JSON backend, where missing/deleting a bracket / brace causes the app to break is out of the question.
My question is, since the meteor web app stores data as JSON documents, is there a way i can access the same JSON from the iOS app? It would really help because then, the person updating the backend only deals with UI, not code. I know this is a pretty broad question, but any pointers would be fantastic. Links, tutorials, frameworks to learn... anything. I've been googling around but can't seem to find anything solid.
Thanks!
You'll want to look into using one of the many iOS based DDP clients, like this one. With these libraries you can connect native iOS apps to the backend of any deployed Meteor app.
As far as I understand, you are looking for a way to get/update the data of your meteor server from the IOS app.
To do that, you can expose an API, like a REST one. Basically, your IOS app will call your Meteor server via HTTP and send/receive JSON data. Like that, you can get your collections, update, add, delete their items as well. There is a lot of literature around REST.
I used a very old one that I do not recommend because it is not maintained anymore, I will put the link anyway Old Rest API.
I invite you to have a look at atmosphere, the meteor package library: Atmosphere. I did a quick search on it and I found this package that looks promising: Simple Rest.
Have a look at the packages on Atmosphere, you can use 'rest' as keyword and pick the one that fits your needs. I am especially thinking of security ;).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
My plan is to make an app for iOS (and android when I've figured it out on iOS) in flash. I need to access data from an external mySQL-database that I will be putting on a webserver. I'm wondering what the correct way to go about this would be.
I've looked a little into AIR, Flex and JSON, but I need someone who knows what they're doing to put me on the right track. I don't need a super in-depth guide, just a hint in the general direction, I can do a lot of research myself, but I'm quite inexperienced in the whole accessing-external-databases-from- flash thing.
Thanks a bunch in advance!
-Flash Newbie
To access an external database you wouldn't use Flash directly, you would need some sort of middle layer (like PHP or Node or Ruby, etc) to get results out of the database and return them to Flash in some format it can understand (like XML or JSON.) This is commonly referred to as an API - it's kind of like a web site but it returns data in code instead of user readable html.
So the flow would look something like this:
Your iOS app would make a request for a url - something like this: http://myserver.com/users
You would have a server-side app (let's say PHP) deployed to a server handle that request.
PHP would query some database (like mySQL) and get the results. Those results would be formatted as JSON or XML and returned.
Your iOS app would get the results, and then you could do whatever you needed with it.
This is super-rudimentary explanation but there is a lot going on with what you're trying to do. My recommendation would be to get really familiar with calling API's on the web (you could use something like https://developer.forecast.io/ to get familiar with working with JSON and web requests) and then when you're feeling comfortable with all of that you could looking into working on the server portion. I don't know what your comfort level is with all of this but a lot of people focus on just one or two of these area's and not the entire stack. It can get overwhelming rather quickly. I haven't even talked about security, authentication, performance, etc... :D
Hope this helps!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
This seems naive to ask, but seriously I have not seen a resource which explains how to work with an API. The basics. More specifically the procedure to start-up with an API.
There are loads of things in the docs. But how to get it working with an RoR app. Like what variables to put in the db, in the attr-accessible. Or is it even required.
Then parsing it in models. Managing from the controllers and displaying/calling in the view. Dont get me wrong, I do know about RoR, I have made apps, but with API, seems confusing. Need to know all the basics.
Is there any resource which teaches to work with an API.
For my scenario, I want to work with a travel API. What should be the first procedure(after getting the API key).
How you work with an API is largely defined by how that API exposes itself, and what libraries of code you have to deal with it.
Many APIs are presented as HTTP endpoints that you can use CURL, OpenURI, HTTParty or something like that to consume the resource, or deal with the data sent to you, often as JSON or XML.
Here is a list of some of the more popular Ruby HTTP API client libraries at the Ruby-Toolbox.
Pick one of these and write some code that gets an endpoint of that API, then use that data to do whatever you need. Treat the API somewhat like a database.
Codeschool has a cool course that you can start with and do the first few levels for free here:
Surviving APIs with Rails
First, before choosing to work with an API or not, I highly suggest to try to work with REST API since these kind usually adhere to the same structure (there is even a book on REST API) and then you know what to expect.
Lets take a fictional Movie DB REST API example
so REST API is all about resources. Every movie can be created read, updating or deleted (CRUD).
so you know that you have these commands in your disposal - if you want to get a movie in your app you would use the read command that the api supplies. It usually looks like GET /movie/13 (HTTP GET request)
so in your app you would have to insert that line whereever you want it (perhaps in some panel where the user search for a movie and you access the movie DB to get the details of it
so you would have a
def movie_panel
#some stuff
#movie = MovieDB::get(movie_name)
end
so now you have the movie.. now what? parsing it is indeed annoying. luckly most API have gems you can use so they did the parsing for you. Here I used the fake gem MovieDB but if there is no gem you need to query the api yourself, which in this case I advise you to build your own gem, or atleast have a module with some classes and method to make life easier for you. something like
module MovieDB
class Movie
attr_accesor :name, :year, etc...
def initialize(movie_params)
#initizalize the movie attributes from a given movie params
#name = movie_params["name"]
etc..
end
end
end
so in this case you would have your own API wrapper to use. So once you are given the movie params from the external API you can do MovieDB::Movie.new(movie_params) and that will create a movie object that has method (that you need to write) for the functionality that you need in your code.
Inside that module you can handle everything about that API and abstract all that from the core of your app.
so to sum up -
REST API - easy, predictable, managable
non/rest api - make sure there is proper documentation
use what the api gives you as a resource, and ask yourself questions - what do I want from the API? what will I do with the resources (such as a movie, or a facebook page, or a tweet)? Does the API docs say its capable of doing what you want to do with the resource?
as documentation goes, you need to read it to understand what to do. No all docs are clear and not everything is clear on the first reading because you don't know where to start. So start at the beginning - why do you want to API? What does the API promise to do? You need to authenticate? Is there a tutorial? Has someone already made a gem for the API?
take some famous API's and not-so famous API as an example.
Facebook Graph API is very well documented. You know exactly what you get from each command and what to expect. You don't need to write it yourself, since Koala gem have you covered. On the other hand of the API rainbow, lies a Pinterest API, which you might wonder what's it for.. No one knows, because its barely useable, you need to get access to it, and even then its very limited. So if you want to plung in to the Pinterest API, make sure you understand what it gives you and what it doesn't (hint - it doesn't). That's true for every API where it has good docs or bad docs.
Good luck and might I suggest to read http://shop.oreilly.com/product/0636920028468.do and maybe this as well - https://github.com/interagent/http-api-design
Update with the actual API
ok so the api http://www.wego.com/api/flights/docs you wanted is documented quite well
the first thing it says is to get the API rate check
GET http://www.wego.com/api/flights/usage.html?format=json&apiKey=testAPIKey
so right here you can begin to structure your code. You need to save the apiKey somewhere and have a url prefilled with http://www.wego.com/api/flights/usage.html and the parameters are the format and the apiKey
you can create a helper method that does that.
def check_rate(format, apiKey)
...
end
inside you will need to send a request and get the response and parse it something like
uri = URI.parse(#url)
https = Net::HTTP.new(uri.host,uri.port)
req = Net::HTTP::Get.new(uri.path)
req.body = ["format=" + #format, "apiKey=" + #apikey]
res = https.request(req)
and that takes you forward one step. Take the result and parse it. Best in this case is to create a class for this kind of response and add methods such as rate_ok? and such. Basically a Class for each response and instantiate a class per response. The constructor of the class would parse the response and expose whatever attributes you need
What I am trying to do is allow users to making postings to Craiglist through my own website using PHP curl. This is NOT an automated posting system, I just want users to be able to post onto Craigslist and my website at the same time. So far, I've managed to log in using php but I'm still not sure how to post the title, description, contact information, etc. I am not familiar with cURL.
Your question is kind of broad, so I'll answer broadly. Narrow down your question (or post a follow-up) so we can help you better.
Is it possible to making a posting to Craigslist through my own website?
It depends, there are two major ways, but most websites block these so I suspect Craigslist does too.
1. Clientside
Your visitors become visitors of craigslist.
You take the form that you find on craigslist, and host it (the html code) on your site, but with the form 'action' pointed to theirs.
They'll probably block these, based on the REFERER, a session key or something alike.
2. Serverside
Your server acts as a client for Craigslist.
You host the form on your server, and the processing page as well. After you've captured all the input, your server will now act as a client to Craigslist, using indeed for example php curl.
You should try if 1 works, if not, start coding on 2. If you're stuck in a specific part, post a question and we'll help you further.
There is an API available now to make automated posts (one or more) in one request.
http://www.craigslist.org/about/bulk_posting_interface
There are two caveats in your case:
It uses RSS as the request/reponse.
Your users will need to provide their Craigslist user/pass (assuming they have an account).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In short, why use something like http://stackoverflow.com/badges/6/supporter instead of something "simpler" (and subjectively, at that) like http://stackoverflow.com/badges/6/.
Even on my own site I've just been using /post/6/ to reference posts (by IDs, even though I still store a slug.) Instead of /post/6/small-rant-on-urls, and in some cases, they can get even more absurd, much more so than is really necessary.
Search Engine Optimisation would be one, as well as making the URL more readable to humans. Search engines generally like your URL, Title and H2 to contain the "topic" of the page.
If you have both in there then you can manually type /ID and get automagically taken to the "flowery" URL with rewriting.. saves your fingers a bit :)
Because you can potentially end up with duplicates if you're not careful. I imagine stack overflow added the ID because there was a high potential for duplicates given the volume of posts created.
Other systems may choose not to use the ID in the URL - for example, a blogging system probably would not need to.
It's a better idea if you have user generated content that results in a new URL created to include a post ID. If the only way new URL's can be created is through administrator type access, you can probably do without it as long as you check for duplicates.
Adding the slug in all links to the content helps with search engines, because search engines will generally use words in the URL itself to help index content.
The reason for including the id in the url is that it makes it easier behind the scenes to retrieve the correct article from the database, as a lookup can be performed on the ID rather than the article's title.
The reason for including the full title of the article, is that Google gives heaps of bonus points for search terms that are matched in the filename.
URL is part of the Web user interface.
There is an eyetracking study of search engine use that found that people spend 24% of their gaze time looking at the URLs in the search results.
Searchers are particularly interested in the URL when they are assessing credibility and usefulness of a destination. If the URL looks like garbage, people are less likely to click on that search hit. On the other hand, if the URL looks like the page will address the user's question, they are more likely to click.
#Greg Hewgill
Adding the slug in all links to the content helps with search engines, because search engines will generally use words in the URL itself to help index content.
I should have clarified a bit: I meant URLs that have both an id and slug in them. I just don't see the point in having something like /post/1/la-la-la-la-text-hahahaha vs /post/1/ or /post/la-la-la-la-text-hahahaha, since the first one would work without the extranous text at the end.
It could be that is faster to get the post in a blog by the id than by the slug, so put the id for the SQL query and the slug for the search engines (SEO).
https://stackoverflow.com/users/58163/movaxes65675
I like the /post/la-la-la-la-text-hahahaha type, i can remember the url, know what the title of the post is (before actually loading the site). Don't like much the /post/1/ it means nothing to me but post #1 (bad for marketing?)
edit: id also helps to avoid duplicates as andybaird pointed
Well, firstly it should be pointed out that the "Web 2.0 style URLs" are actually part of something called REST. Those URLs are sometimes called RESTful URLs. The claimed benefits are:
Provides improved response time and reduced server load due to its support
for the caching of representations;
Improves server scalability by reducing the need to maintain session
state. This means that different
servers can be used to handle
different requests in a session;
Requires less client-side software to be written than other approaches,
because a single browser can access
any application and any resource;
Depends less on vendor software and mechanisms which layer additional
messaging frameworks on top of HTTP;
Provides equivalent functionality when compared to alternative
approaches to communication;
Does not require a separate resource discovery mechanism, due to
the use of hyperlinks in
representations;
Provides better long-term compatibility and evolvability
characteristics than RPC. This is due
to:
The capability of document types such as HTML to evolve without
breaking backwards- or
forwards-compatibility; and
The ability of resources to add support for new content types as they
are defined without dropping or
reducing support for older content
types.