Posts by Dani

Labdabeta, post your question in the appropriate Software Development forum but tag the thread daniweb-api

Yes, you can enter something like http://localhost

I would know how to make such a program if all the daniweb data was kept on a hard-drive on the users machine, but obviously it isn't.

All you need to do is scrape our API and duplicate its contents on your local hdd in a format that you are able to parse and work with. Would that work?

Everything that you're suggesting is definitely 100% doable, but unfortunately I don't have any experience with non-web based languages to be able to give you a hand.

Someone else is already doing an iPhone native app, but it is still heavily in the works. I'm also not sure if he's going to submit to the competition.

Not sure what you mean by "valorate"?? Do you mean evaluate? If so, it's a work in progress and probably won't be released until after the competition is over.

Why the sad face?

I don't particularly want to get into an argument with you

I wasn't trying to argue. On the contrary, I trust your advice when you say I'm not implementing the spec perfectly (when I thought I was), and so I was asking for the documentation of how it should be changed.

In OAuth 2.0 the redirection URI is an optional parameter as described by the RFC: http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-4.2.1

Can you please point me to where in the RFC document it says what the appropriate behavior is for the API if a redirect_uri is not present. I see where it says it's optional, but the server essentially is meant to return a redirect with the values needed (code and access_token) tacked onto the query string. If a redirect_uri is not provided, how should the API respond with the values??

Also, for those who missed the notice, the code snippet competition is being extended to the end of August for submissions

I also presume that the mobile developer you spoke to use custom schemes in the redirect_url to call straight back into your app. It's this that I'm trying to avoid in order to stay true to the way OAuth was intended to authenticate.

He showed me finished projects for iOS that both used embedded browsers and that didn't. They all looked very well-polished from the end-user standpoint although I have no idea what went on behind the scenes. He said he finally has the navigation working and is now working on the non-OAuth requests before playing around with OAuth, so he cannot comment about DaniWeb's specific implementation yet. I'm looking forward to his feedback since he has so much experience working with OAuth with a wide assortment of APIs.

This brings me on to another point. Whilst I agree that "this is how it's done" nowadays, don't be a lemming :P Just because everyone else embeds the browser and [has the ability to] steal the user credentials doesn't mean we all should.

While such deficiencies may exist for using OAuth in non-web based mediums, I believe this to be a case where I can't just choose to "not be a lemming". Sometimes you have to do things the way that your audience expects them to be done in order to ensure the desired reach.

Finally, and this is more appropriate to Daniweb itself, the OAuth authentication as it's written doesn't follow the correct flow when trying to authenticate natively. Specifically, there is no standard result page, nor JSON/XML result where the redirect_uri is missing or some optional scheme that we can use for mobile/native development. Without this, we have to jump through all the hoops mentioned above.

Can you please explain what you mean by this? From what I understood from the implementations of Facebook, Github, Stack Overflow, and all of the other implementations I tried my best to imitate (for the convenience of the developer being able to use a single library to connect to all of them), the standard behavior is for an invalid request http error to be passed if a required parameter (such as redirect_uri) is missing.

http://www.daniweb.com/community-center/geeks-lounge/threads/451027/daniweb-api-developer-competition#post1952715

'Limited' was not a pop at the API - as I said - more to do with my attempts to wangle data out of it that it wasn't designed to give (as you mention).

On the contrary, the API was designed to give the flexibility to do nearly everything conceivable to the imagination. However, in order to offer that level of flexibility, we can only provide you with the building blocks and then leave it up to the developer to put them together in an infinite number of different combinations. The API would be much more limiting IMHO if we provided more "polished" data as opposed to just the raw building blocks.

You can do a lot with a bundle of logs, your imagination, and some skills but your choices are a lot more limited when they're already all precut into 2'x4' planks. Sure, it might seem a lot less daunting interlocking some two-by-fours to build something simple, as opposed to staring blankly at a giant heap of lumber, but ultimately the flexibility and infinite potential is no longer there.

Fair response, Apple are the only ones with easy native integration from what I've been told.

I don't have any mobile developer experience either way to be able to compare. However, OAuth is incredibly popular nowadays, as it powers the APIs for Google, Facebook, Twitter, etc. so I can't imagine that the Android market would shoot themselves in the foot like that.

Did try the embedded browser authentication myself but ran into difficulties on the second call, when using the browser to do it, to OAuth with the application code and stopped.

I only have web development experience, but Matt showed me examples that he wrote using OAuth that both used the embedded browser method and that didn't. Additionally, I've of course seen the embedded browser method in practice many times (i.e. Windows 8 with Facebook and LinkedIn integration) so it's obviously doable. We follow the exact same flow as Facebook.

Just hit me when I tried to search for particular data.

As I've mentioned, the API opens up all of the backend model-layer functionality (MVC model) that the DaniWeb website uses. We are incapable ourselves of performing search queries, which is why we outsource our search functionality to Google. The API allows you to do anything we are able to do.

Not having a go - I was just trying to get at data that wasn't possible throught the API interface, e.g. a traditional SQL INNER JOIN :)

That's the point of the API: to create functionality that doesn't currently exist in core DaniWeb. If native DaniWeb doesn't have a need to do the particular INNER JOIN query, then it's not going to be a native feature of our API either. Otherwise, our native application would be so bloated with every possible, potential combination of query that could ever be thought up for one reason or another. However, that doesn't mean that you can't access our content and perform the query on your end. Scrape our API and reproduce the portions of our database that you will need for your application. Then query your own partially recreated database. It's doable and the fact that you need to do the processing on your end instead of just querying us for an instant response is what would make your application valuable.

The API is NOT designed to give you a means to query our database for various combinations of resultsets. It's designed to give you the building blocks for you to build your own invention on top of.

Also tried making a POST request for this stage using the RestSharp library for C#, however just got an internal server error (500) when I did so.

Unfortunately I don't know C#, but perhaps you can find an OAuth library in C# for Facebook, Stack Overflow, Github, etc., and modify it to use DaniWeb instead.

I was looking at developing that very thing, but where do we get the logged-in users data? I couldn't see how the api could give that info.

Fetch a list of members from http://www.daniweb.com/api/members and they will be sorted based on last logged in date.