Jump to content

Web Services


bamageek

Recommended Posts

I think a cool future enhancement would be to implment the search page/pocket query functionality into a web service. By implmenting a standard web service (and possibly even publishing the service on a UDDI registry) other developers can invoke the search and/or pocket query functionality from their applications. The service could return the cache information using the same XML schema that is currently used for the GPX files.

 

I believe this would also help offload some of the high volume traffic that Groundspeak currently sees during peak times because instead of having users online for a large period of time the third party application would simply invoke the service and get out.

 

Dave

Link to comment

Our big barrier is coming up with a decent login scheme. I did a test one where you pass your username/password along with your log information, but I'd rather have you log in first then pass credentials along with your log entry.

 

I've been perusing the documentation on MSDN on how to do this with session tokens.

Link to comment
Our big barrier is coming up with a decent login scheme. I did a test one where you pass your username/password along with your log information, but I'd rather have you log in first then pass credentials along with your log entry.

 

I've been perusing the documentation on MSDN on how to do this with session tokens.

I worked with this on a Java project a bit. We ended up using HTTP basic authentication. I have a front-end servlet that handles my authentication and then passes control to the web service. On the client side, many tools like MS SOAP Toolkit are already equipped to handle authentication, but for others it may be a challenge to manually code this. The good thing is, since its HTTP basic theres lots of help available...

Link to comment
Our big barrier is coming up with a decent login scheme. I did a test one where you pass your username/password along with your log information, but I'd rather have you log in first then pass credentials along with your log entry.

 

I've been perusing the documentation on MSDN on how to do this with session tokens.

What's wrong with the authentication already available with HTTP?

 

This isn't a troll; it's a an offer to help with other options if we can understand the objection for not using the HTTP standard scheme...

Link to comment
I don't object to it, if you think that most developers will feel comfortable coding against it.

The hardest part of coding around the Base64 encoding. Its easy in Java, but in other languages there may or may not be an encoder freely available. I found some VB source code that works about 90% of the time. The MSSOAP control is really easy because it does the work for you. Not sure about other languages though...

 

If you're not worried about security you can always throw it in the SOAP header, but the HTTP header is the most secure.

Link to comment
I've been perusing the documentation on MSDN on how to do this with session tokens.

BTW, I don't know anything about ASP, but I understand that the MS SOAP control supports sessions so I'm sure that is possible. Probbably would be more efficient if you could log in one time and then work with a session cookie.

Link to comment

Security probably isn't as big of a deal here as it would be in some cases. Of course you don't want somebody logging finds for you... :) I think users will be a bit more acceptible of the concept though if there is a bit of security involved. I know some folks do have issues with providing their userid and password to somebody.

 

I'm sure that whatever you guys do will be great. You've done an excellent job so far!

 

Dave

Edited by bamageek
Link to comment
Coding against it? What could be easier than username:password@www.geocaching.com/blah ?

That doesn't fly so well when you're doing the HTTP implementation yourself :o

 

Base64 isn't that big a deal in the first place, though... if an encoder function doesn't exist for a language (which it does for most, if you look hard enough), write one. It's not that difficult.

 

SSL, on the other hand... it may be supported across most platforms now, but not across all versions of all platforms. Palm OS doesn't do it until version 5.1, I think, and it's extremely difficult (read: impossible) to upgrade an OS 3.x device to that.

Link to comment

SSL, on the other hand... it may be supported across most platforms now, but not across all versions of all platforms. Palm OS doesn't do it until version 5.1, I think, and it's extremely difficult (read: impossible) to upgrade an OS 3.x device to that.

 

Not to be unsympathetic (and you know I'm a cross-platform/standards kind of guy) but it doesn't strike me alarming when a platform that by any reasonable definition doesn't support internet connections makes it impractical to do web services.

 

OK, your 3.x device with the strap-on field modem thingy or Palm VII might not be able to do SSL directly wthout undue pain. But transferring that to your desktop - where you almost certainly do have the horsepower to do SSL - doesn't seem so bad. Right?

Link to comment
OK, your 3.x device with the strap-on field modem thingy or Palm VII might not be able to do SSL directly wthout undue pain. But transferring that to your desktop - where you almost certainly do have the horsepower to do SSL - doesn't seem so bad. Right?

I gotta admit though being able to log finds on the spot sounds very intriguing! :o

Link to comment

FYI: In related thread: "Logging Caches By E-mail And Batch", I suggested a file format that might be used to transmit the information involved in logging a cache find.

 

If the security issue can’t be solved, then perhaps a file consisting of “proposed logs”, or “proposed actions” (e.g. TB drops), can be accepted as an ASCII file, parsed and displayed on one (long?) web page where we could scroll through to view and click a check-box to accept or delete each proposed action. Then proceed with writing all the entries to the database by having the user click a button at the bottom of the page. That would allow some proofreading and verification by the person who supposedly submitted the list of logs. It would deal with security because it would require that the user be logged.

Link to comment
Not to be unsympathetic (and you know I'm a cross-platform/standards kind of guy) but it doesn't strike me alarming when a platform that by any reasonable definition doesn't support  internet connections makes it impractical to do web services.

Good point. I should know that firsthand, actually, considering the pains in trying to do an IRC client for Palm OS. I was a success in that, but it's kinda limited mainly because of the (at least pre-5.x) Palm OS TCP/IP stack.

 

OK, your 3.x device with the strap-on field modem thingy or Palm VII might not be able to do SSL directly wthout undue pain.  But transferring that to your desktop - where you almost certainly do have the horsepower to do SSL - doesn't seem so bad.  Right?

This is true. Speaking of cross-platform things, that could still be done on most of them with OpenSSL... a conduit for Windows, and a program for all of the others that would read the PDB file storing logs to be uploaded and post those to the server. If the PDA were SSL-enabled, a separate program could do the upload from there. I've done an HTTPS server before, so a client shouldn't be any harder.

 

AvantGo does something similar, and they can do SSL with a desktop machine. Looks like they can do that on older Palm OS devices as well, but probably with their own SSL implementation. I'm not quite willing to go that far, though :o

Link to comment

This is a little off of the subject, but I'd like to see you guys work together on this one. You guys have done an excellent job on these supporting applicaitons. I use CacheMate and GSAK regularly and enjoy both. I'd love to be able to write quick log notes in CacheMate and go back to my computer at the end of the day and upload them to a desktop applicaiton like GSAK. From there I'd like to be able to review my logs and make any modifications, and then submit them to Groundspeak.

Link to comment

I should mention that I wasn't unhappy with how the logging interface used to work; it was simple and effective. I'd send a username and a password and get a cookie back. Armed with only that cookie and GC#'s, I could post forms containing the log type, date found, and log prose for the next, uuuh, 24 hours or something. (TB's, additional waypoints, and photos I didn't bother with since they weren't the bulk of my logs) We didn't have to roundtrip to the server to get a new cookie or viewstate for every page. Once we had this cookie, we had to await only the page containing either the database timeout or a confirmation "congratulations your visit has been..." page. It was speedy, trivial to code, and resulted in fewer pages being served up by your host.

 

http://forums.Groundspeak.com/GC/index.php?showtopic=68251

 

Web services and SSL aren't computationally inexpensive. Please do consider if this is a problem worth solving well or if the return of a simpler interface (i.e. one that required the ASP.NET_SessionId cookie returned during a login that accepted the key input fields including the GC#[1]) would solve the majority of logging needs. The fields can be POSTS instead of the sort of mixture in the old interface. The key to this working is to not require a viewstate for each log that can only be obtained by fetching the 'log this cache' page. (If you could publish the forumula to compute a viewstate from information in a PQ, the web services logging thing might become less interesting anyway.) Additional fields for coords, mailing the cache owner, travel bugs, and fotos could make that a complete interface if you want to pick up those last 10% of the logs that needed a fuller interface.

 

It's worth noting that this approach does require one page delivered each way for each log while a "real" web services interface could batch them up. (Ten logs could be one large interchange instead of ten.) But the ack page could be essentially a static page and therefore inexpensive to serve up. It's also a much simpler interface for both ends of the conversation which might outweight the computational costs of XML parsing, SSL encoding, and programmer time.

 

Actually there's a good topic for the developers list: what's wrong with the logging interface and why to people want to avoid it?

 

[1] Base 31 or decimal; it doesn't matter which as long as you keep the public conversion formulae up to date as you've done. I'd rather it not be a GUID as the PQ's only in one place that's difficult to extract.

Link to comment
True. But we're not sending the password every time for requests to the web site.

Just to throw another option into the pot...

 

What about sending a hash (MD5 is reasonably common) of the password / date / hour in the XML schema? It's not cleartext, is valid for a limited period, is stateless, and it keeps it a "single technology solution", rather than relying on bolt-on layers of security that just increase the complexity of clients.

Link to comment

You know I think for the purposes of the site the SSL certificate may be a bit overkill. I think if you simply encode the password with a Base-64 encoder and throw it in either the HTTP header or the SOAP header that will work fine.

 

As for expenses, I don't have any experience with asp or .net, but I know from a Java perspective there are free open source options for creating and running Web Services which work fine. On a client side, you can always simulate web services using a simple HTTP Post. I wrote a little VB6 client that I use to test my service and this is all it does. I have also worked with some clients who did this from an OS/2 script and it worked fine for them.

 

Dave

Link to comment
As for expenses, I don't have any experience with asp or .net, but I know from a Java perspective there are free open source options for creating and running Web Services which work fine.

Web services are built into the .NET framework, it is nothing to add on. In fact, most code can very easily be converted to web services by simply changing the line where the function is defined. And because it is built into the framework already there is really no extra overhead to add the functionality. No real difference to the server than handling a request for a web page.

Link to comment

Out of curiosity, has anything more been done with this, or am I still subscribed to this thread after 2 years for no reason? :blink:

 

I've had several requests for direct logging from CacheMate to the site, and it would be great if there were a standard way to do this instead of having to code something to work against a web-based login and form submit that could change on a whim and break everything. The latter is something I'm not likely to do, exactly for the reason stated.

Link to comment

Web services are built into the .NET framework, it is nothing to add on. In fact, most code can very easily be converted to web services by simply changing the line where the function is defined. And because it is built into the framework already there is really no extra overhead to add the functionality. No real difference to the server than handling a request for a web page.

 

Please, please, please! What ever you do make sure that you still have interoperability with Java and other major languages. Consider follwing WS-I's Basic Profile. This makes sure you do not use datatypes that aren't supported by other languages (such as the dreaded DataSet...) or use schema specifics that are not easily understood by most other platforms. Microsoft has added a lot of great features to .Net, like WCF, that are not interoperable out of the box, unless you stop and think about it.

 

Interoperability must be absolute key for a site like geocaching.com.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...