[NUUG fiksgatami] FixMyStreet integration & v2 spec questions

Petter Reinholdtsen pere at hungry.com
Tue May 3 09:51:51 CEST 2011


[Philip Ashlock]
> Expected language:
> Could the preferred language supported by the endpoint just be denoted
> by the accept-language http header response of the services list? From
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

It probably could.

Note that users can not be expected to have their browser configured
to list their prefered language in this header.  At least in Norway, a
lot of users have their browsers "incorrectly" set to prefer english
while the user prefer one of the norwegian varians (nb or nn).  So the
user provided value can't be trusted.

> Would this approach be inconsistent with they way we're using
> service discovery? Would it be better to try to rely on the service
> discovery method more exclusively than http headers like this? As
> far as standards and RESTful approaches go, accept headers are
> clearly established, but i'm not sure if that translates to use in
> practice and developers' preference.

I suspect a more explicit method is better.

> Multiple Administrations:
> The ability to distinguish multiple administrations with one API
> endpoint is something that the jurisdiction_id is meant toi be able
> to denote. I think the SeeClickFix endpoints are using lat/long for
> now on specifying service requests, but I'm not sure that was
> something we'd actually included in the spec (not yet at least).

For FixMyStreet in Norway, the issue is that we send the same reports
to several councils and administrations as long as we are unable to
determine automatically which one should have it, and leave it to the
two to figure out which one should handle it.  And the recipients are
determined by geo-location and category.  The jurisdiction_id do not
seem like the right approach for this.

I'll stop there, to see if my email make it to the list.

Happy hacking,
-- 
Petter Reinholdtsen


More information about the fiksgatami mailing list