On 21/01/2014 2:45 PM, Timothy Sipples wrote:
Robert Rosenberg writes:
There is a limit on how long a URL can be. That type of URL gets long
very fast if you are embedding the actual data into it.
Yes, but staying within 2000 characters is generally regarded as safe,
which is presumably a lot for the sort of ancillary data Brian wants to
transmit. Also, there's no particular requirement how to encode the data.
You could use something like this:
...myurl.com?data=abcdef...
Not a bad idea. Although I prefer to use the URL without a query string
myurl.com/apiv1/abcdef. I'm a big fan of RESTful
APIs.
where the data ("abcdef...") consists of one long string of parameter
information that has first been compressed (e.g. AMATERSEd) then
pseudo-xxencoded (shorter) or hex coded (longer), for example. You are not
required to use the classic param1=xyz?param2=123?param3=abc sort of
format.
There are tons of URL safe base64 encoders/decoders out there
For some degree of future proofing, instead of data= you might choose
myprodcode1.0= so that you can change the format in the future but still
interpret and support the old encoding format if necessary.
Shmuel Metz writes:
That won't work for e-mail clients that don't support clicking on a
URL.
That's true, but it's also presumably true that the installations sending
these e-mails would control their format (via a parameter in the product to
switch between plain text and HTML e-mail output, ideally per user) and
have at least indirect management authority over the recipients and thus
influence their e-mail capabilities. I don't think these e-mails are
getting sent to arbitrary individuals.
In other words, I don't think having e-mail clients with clickable (or
tappable) URLs (to internal Web sites) is an *unreasonable* prerequisite to
enjoy this ancillary functionality, especially in 2014 and beyond.
--------------------------------------------------------------------------------------------------------
Timothy Sipples
GMU VCT Architect Executive (Based in Singapore)
E-Mail: [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
