Domains in the uri

#1

who uses reverse domains in your URIs? Have you found it helpful? Has it enabled simpler designs? If you're not using them have you discovered that you should have?

I know the recommendation is to add them to prevent conflicts but We've been using crossbar going on 2 years now and we haven't been using reverse domains up to this point, our URIs look like this 'auth.oktai.password.verify' it hasn't been a problem yet.

we're putting together a technical doc on integrating into our apps via crossbar and revisiting the recommendation, on one hand it makes sense to require 3rd parties integrating into our app to include their domain e.g. 'com.example.password.verify' but doing so means we should to fully adopt the convention and refactor all of our URIs so ours would become 'com.ourdomain.password.verify'

I'm hoping someone can offer advice for our against to help us determine if it's really important or not.

0 Likes

#2

i habitually use reverse domains since several of my crossbar routers serve projects for multiple purposes. i habitually do this elsewhere too, for the same reason

···

On Sat, Feb 25, 2017 at 7:08 PM Greg Keys gk...@mumbacloud.com wrote:

who uses reverse domains in your URIs? Have you found it helpful? Has it enabled simpler designs? If you’re not using them have you discovered that you should have?

I know the recommendation is to add them to prevent conflicts but We’ve been using crossbar going on 2 years now and we haven’t been using reverse domains up to this point, our URIs look like this ‘auth.oktai.password.verify’ it hasn’t been a problem yet.

we’re putting together a technical doc on integrating into our apps via crossbar and revisiting the recommendation, on one hand it makes sense to require 3rd parties integrating into our app to include their domain e.g. ‘com.example.password.verify’ but doing so means we should to fully adopt the convention and refactor all of our URIs so ours would become ‘com.ourdomain.password.verify’

I’m hoping someone can offer advice for our against to help us determine if it’s really important or not.

You received this message because you are subscribed to the Google Groups “Crossbar” group.

To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+...@googlegroups.com.

To post to this group, send email to cross...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/a9be25f3-6fc3-41be-a207-03da17ad48fa%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

0 Likes

#3

Hi Greg,

those are all good questions;)

I'd be interested about what others do / opinions too!

We've been using mostly 2 patterns, the "full"

[1] com.example.<product>.[<module>.]*<function>

and the simplified

[2] <product>.[<module>.]*<function>

And indeed, if <product> is sufficiently unique, there doesn't seem that much value to having the "com.example." prefix, to bind it to the domain name system to make URIs unique by that.

Even if you throw together 2 products in 1 realm, it should collied.

So if I had [2], I probably wouldn't go through the efforts of migrating to [1].

···

--

But as far as I understand, you don't have even a <product> prefix?

auth.oktai.password.verify

Or is it "oktai"?

--

Another thing that we've been doing in 2 different ways at times:

"create-product"

vs

"create_product"

The former IMO looks nicer for URIs, but isn't a valid identifier in most languages.

Cheers,
/Tobias

Am 26.02.2017 um 01:08 schrieb Greg Keys:

who uses reverse domains in your URIs? Have you found it helpful? Has it enabled simpler designs? If you're not using them have you discovered that you should have?

I know the recommendation is to add them to prevent conflicts but We've been using crossbar going on 2 years now and we haven't been using reverse domains up to this point, our URIs look like this 'auth.oktai.password.verify' it hasn't been a problem yet.

we're putting together a technical doc on integrating into our apps via crossbar and revisiting the recommendation, on one hand it makes sense to require 3rd parties integrating into our app to include their domain e.g. 'com.example.password.verify' but doing so means we should to fully adopt the convention and refactor all of our URIs so ours would become 'com.ourdomain.password.verify'

I'm hoping someone can offer advice for our against to help us determine if it's really important or not.

0 Likes