How to implement address search in JSON API?


#1

Hi,

Since id is mandatory property for all resource objects I’m not sure how to implement a geocoding API that conforms to JSON API.

Addresses (at least in our system) are value objects. That is, they don’t have identity. If I was to query the API using something like this:

GET /address/?street=broad

I would like to get back a result that looks something like this:

{
    "data": [
        {
            "attributes": {
                "lat": 41.863920,
                "lng": -87.853393,
                "street": "Broadview"
            },
            "type": "address"
        },

        ...

    ]
}

I don’t like the idea of generating fake IDs since that is misleading to the client.


#2

Is it possible to get an address without searching? If so, what does it return exactly?


#3

No, not really. In the API, addresses are always part of some other entity (an order’s delivery address for example).

The geocoding API is there to validate user typed addresses and to find lat/lng coordinates to be copied over to an entity. (similar to google’s geocoding service)


#4

In what way is the client misled? Because the client thinks it knows an ID that the API / server uses? But the client cannot use this ID (it can’t lookup an address using the ID). Although it’s a leaky abstraction I’m struggling to see what potential problems this could lead to.


#5

The spec states:

Within a given API, each resource object’s type and id pair MUST identify a single, unique resource.

In your case, you could give the lat/lng comma-separated as an id.


#6

Exactly. I think you are answering your own question :slight_smile: It can be done for sure. The server can generate transient and unique ID numbers on the fly and maybe there are no real problems with this. But as you say, it’s a leaky abstraction and misleading the client to think that these IDs have some meaning and can be referenced to later on.

I guess I was just hoping that I missed something in the spec and that there actually was a nicer way of doing this that I just hadn’t realized.


#7

Or use meta for non-resource object responses


#8

Why not use “filter” query param? e.g., GET /addresses?filter[street]=broad will response:

{
    "data": [
        {
            "type": "addresses",
            "id": [md5(lat + lng) for example],
            "attributes": {
                "lat": 41.863920,
                "lng": -87.853393,
                "street": "Broadview"
            },
        },
        ...
    ]
}

#9

if some one can how implement address in josn api…