Hacker News Reader

Comment by sbr464 | Hacker News Reader

I don’t mind using a link, but I’d prefer to have both the exact id and the link to avoid having to parse a link in an unreliable way to get the actual id.

It’s interesting how GraphQL changes the base point of the article concerning documentation/ease of api use.

In our GraphQL resolvers we typically add two fields, thing_id which resolves to the id string, and thing which resolves an object that you can drill into as desired.

I was starting to see a lot of GraphQL APIs only add “thing”, which meant you had to do a lot of queries like below just to get the id.

  thing { id }

View on HN

thing { id } comes from the Relay specification and it can well be a URI:

Node Interface

The server must provide an interface called Node. That interface must include exactly one field, called id that returns a non‐null ID.

This id should be a globally unique identifier for this object, and given just this id, the server should be able to refetch the object.

https://facebook.github.io/relay/graphql/objectidentificatio...

I agree, and don't mind, We've just decided to add in both fields thing_id & thing, for parsing convenience.

I guess most schema designs wouldn't duplicate each field just for that convenience, as it doubles the number of fields in documentation, autocompletes etc. as well.

I suspect the link is the id, as in uniform resource identifier. So parsing would be a mistake. At least on the client side.

When you are orchestrating an interaction between several services where they are all using a shared identifier somewhere in their API, you need to extract that identifier if it's embedded in a URI.

So tonight we're going to regex like it's 1999.

Most modern ecosystems have fantastic URL parsing that does not rely on regex and should not be written again by hand.

The identifier is not embedded in a URI, the identifier is a URI: instead of an integer id 1234 or a string id "1234", you can use a string id "http://example.com/id/1234". Typically, one service is responsible for creating the id but after that, it can be used to refer to the same entity in any number of services. EDIT: What makes it better than a free-format string id is that every person and tool knows how to de-reference it / look it up.

What determined which API owns a resource when the same resource is exposed in mutlipe apis (e.g you have a REST API and a AMQP feed)? In some cases it is obvious but in other cases it is far from clear.

I feel using urls as ids create more problems than it solves, especially if you use absolute urls. I have worked with cases where the same ID was used in 3 or 4 different APIs. None of them clearly the master.

The URI doesn't have to be fully owned by any single microservice. The JSON representation can more or less correspond to a HTML view and be served by the UI, or a separate API facade can combine the relevant pieces of information from various microservices.

You would still often need to parse them. Imagine that the url is the primary key of a table and the API changes url structure. Then you would get duplicate rows and the only way to prevent that would be to validate the format of the urls, which is parsing. The index would also be bloated and slow.

If you follow this model consistently, the client never needs the concept of an "actual id". For the client, there is only one Id — the URL. The client can use it anywhere that in other models they might need to use an "actual id"

Reply on news.ycombinator.com