@pauljbarton, you're right that staying within garmin's closed world sadly is the most reliable option. it's just sad to see the wasted potential of the fenix. and personally i cannot get myself to use something that's 15 years old and you can tell, when there's also stuff like strava's route builder that is better in every possible way (other than the fenix occasionally crashing when having to process an exported GPX).

hello sean. thanks for your feedback and comment. i am not 100% sure i understand your question. when you upload a route to your fenix, no mobile signal is required at any time. the route contains GPS coordinated. your fenix will acquire a GPS fix (no mobile network needed) and then you can navigate along the route. in fact, that's my main use case: having navigation in areas where i have no mobile coverage. if i have mobile coverage, garmin has made uploading routes sufficiently painful that i stopped doing it by watch and simply use my phone, either using google maps or with my strava-planned route in the strava app. another issue that i have had is that the fenix crashes a fair bit when navigating. friends report the same thing. it happens pretty often, may 1 out of 10-20 times. garmin has done a bad job testing their watch with standard GPX files. since i have had that happening a number of times, my confidence in the fenix as a reliable navigation device is low. i wouldn't bet my life on it. the reason for all of this is that garmin does not understand how much happier their customers would be if they had an open mind. instead, they insist that the only "supported" route upload is via garmin connect, which is really bad at route planning. anyway, it's garmin's old problem to understand that they exist in a bigger ecosystem of services, and that developing robust standards-based software would increase the value of their devices dramatically. i have lost hope in garmin understanding this, and i am quite curious to see how the fenix 5 will do: is it even more closed than the fenix 3, or does it at least still have this narrow (and badly implemented) way how people can play outside of the garmin-only universe?

@sebastienmaret, definitely let us know should you learn anything interesting about the spartan. from my experience with suunto, their software (the on-device part) is close to being unusable, but from what i've heard they have made quite a bit of progress. i haven't read any experience reports of the spartan yet, and i am curious. the hardware definitely looks as if for the first time they may have something that is on even footing with garmin, but there are many ways in which firmware or software might give that opportunity away. personally, i hope that they get it right, because it would be good to have some competition for garmin.

thanks for comment and the link, @Sebastienmaret! i did not know this service existed. all hail the strava labs! i just hope somebody at garmin will notice how much they hurt themselves by forcing people to jump through all these hoops, instead of embracing the fact that people not necessarily love connect.

hello @rob and @zosia: i also had issues with some tracks and was never entirely sure what caused them. some even crashed the fenix to the point where it was constantly rebooting. apparently, garmin has some serious bugs in the code that reads the file. my hunch is that the problem can be triggered by the file name, or by the title of the track (in the file). so maybe experiment with those two? good luck and let us know how it went!

hello @lblackmore. all agreed on garmin's general inability to create good software. which makes it even more confusing why they are not more open in their approach: after all, they must realize how much they lag behind in software and services. but garmin always has been very closed, so as long as there are at least little holes, it's better than nothing. it's great that the fenix 3 reads GPX, that's some sort of standard. those units that have been locked down further, such as the 910xt and the 920xt, are a bigger problem. afaict, the closed FIT format has no support for waypoints, so there simply is no way how you can get them onto these units in a free and open way. it's a shame that nobody at garmin seems to understand how much they could gain by being more open. but i've given up hope on that one, and i am simply glad when from time to time, there are little holes in garmin's iron curtain.

hello @neil. i do not know whether the fenix HR model behaves the same. it has different firmware, so it's hard to tell without trying. maybe ask the fenix facebook group https://www.facebook.com/groups/GarminFenix3/ about this. about the ease of navigation: once you have he route on the watch, navigation means following the line. i can be a bit tricky and garmin could improve the navigation screen a fair bit. but it's good enough to figure out when you are off-track, and that alone can be very helpful.

thanks for your comment, @jan! me and my colleagues at the API Academy often joke that we should have a one-slide workshop on API versioning with the one slide saying: "DON'T!" of course that's not terribly helpful, but it really is what you should be striving for. as a follow-up to http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html i am planning on writing in more detail on how to design APIs this way. the key point really is to design in a way that you don't need to version; all you do is evolve, and there's no need for version labeling at all. if you do reach the point where you make non-backwards-compatible changes, you start breaking the ecosystem and there's no need to call this "versioning" anymore: you're creating a new thing and the main/only reason why you might want to keep the name is branding. for now, i highly recommend to read mark's https://www.mnot.net/blog/2012/12/04/api-evolution which touches on all these points, and also highlights the fact how using web architecture makes you think about versioning in a very different way.

thanks for your comment, @peter! i absolutely agree that "self-describing" does not imply "no documentation". and that's not what REST means by that term. it simply means that you don't need out-of-band information to act on a message. when it comes to documentation, which one of the basic Web Concepts (http://webconcepts.info/concepts/) you are using already is a very good starting point. but then you still need to document your media types and any non-standard concepts you're using. the API documentation space still has a long way to go! about the vacation example: your *client state* goes on vacation, too, but not the *resource state*. let's assume you browsed a library and asked about the available copies of a book. your result showed three books, and then you went on vacation. when you come back, maybe not all of those three books are still available. but your client state assumes they are. so you click on "reserve", and then the server responds with "this book is no longer is available". this is why REST clients have to be able to deal with failure *at every single step*, because this scenario can happen anytime.

thanks for your comment, @tim. and yes, you're right that a link between two services establishes some kind of coupling. that's because when you follow the link, you now interact with the linked resource. you could classify this kind of "coupling" as "choreography", where interactions lead you step by step. that would be different from more classical "orchestration" approaches, where you have a single grand plan and that's what you follow (if you're interested in the different ways in which you can look at "coupling", http://dret.net/netdret/docs/wilde-www2009-loosely-coupled.pdf is a paper cesare pautasso and i wrote a while ago). the neat thing about REST hypermedia is that it makes "decentralized choreography" a natural part of the design and interaction model. and because it is stateless, meaning that each request is completely self-contained, you are able to choose between steps if there is more than one available. let's idealize a bit here: let's assume you have shopped and now you have three options to pay. the shopping service is "coupled" to these three payment services in the sense that you probably will pick one of these three, based on your preference. in a perfect RESTful world, though, your shopping service would expose a "user x with shopping cart y needs to pay z dollars" resource, and you could even pick a non-affiliated payment service, as long as that service would be designed to work with these "i am x and have order y for z dollars to pay" representations, and your shopping service would expose this kind of resource and also provide a payment protocol for that other service to make the payment. now that may be a bit of a stretch here, in particular because payment is such a sensitive area, but maybe it highlights a bit what the hypermedia coupling does, but also where well-designed hypermedia APIs allow clients to opt out of them, when clients don't want to use the provided hypermedia controls.

good to know this post helped you, @tim. sadly, garmin still lives very much in a closed world where they assume everybody is only using their devices and services. it always seems odd to me how a company can ignore the potential of better playing with things outside of their control, but the majority of companies are not great at understanding the value of openness.

Thanks for your comment, @herbert. Here's my response, but as usual, that's just my view of things, and very often it's more productive to discuss concrete scenarios and applications instead of just doing spec exegesis. But since i have written the one in question, that's what i was indulging in with this post... 1) Have you seen "type" being used for indicating a MIME type? That would be terrible, since that's definitely not what it's for. I have not seen it used much, and the spec is very fuzzy and talks about linking to an "abstract semantic type": https://tools.ietf.org/html/rfc6903#section-6 i am not sure what that's supposed to mean, and one of the REST principles is that the "type" of a resource in indicated by its MIME type, period: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven "A REST API should never have “typed” resources that are significant to the client. Specification authors may use resource types for describing server implementation behind the interface, but those types must be irrelevant and invisible to the client." The idea behind profiles is that they are optional hints: things continue to work without them, they are just convenience labels you might use to refer to a certain "property bag" that you use or expect to be used. That's very different from a type. 2) A profile says "This animal says you can treat is a duck". A schema says "here are all the rules an animal needs to follow to be considered a duck". A profile might have a schema, but very often instead of that, the schema governing it will be that of the underlying media type, plus additional constraints which often are extensions. Consider the podcast: The podcast spec does not provide a schema replicating all feed constraints and adding the podcast fields. It could, but that's not what I would do and frankly, I have never seen it done that way. Instead, the schema governing the podcast is still whatever schema defines a feed (let's assume the RELAX NG for Atom), and the profile simply identifies the set of properties that's used in addition to that schema. As a result, a podcast, when linked as extensively as possible could link to its schema which would be the vanilla feed schema, as well as its profile, which would be the podcast feed identifier URI (which is just an identifier and not a locator, per spec).