4 ms·
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’
by sbr464 7y ago
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 }
- rileymat2 7y agoI suspect the link is the id, as in uniform resource identifier. So parsing would be a mistake. At least on the client side.
- mypalmike 7y agoWhen 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.
- smt88 7y agoMost modern ecosystems have fantastic URL parsing that does not rely on regex and should not be written again by hand.
- tuukkah 7y agoThe 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" 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.
- jeltz 7y agoWhat 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.
- tuukkah 7y agoThe 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.
- jeltz 7y agoYou 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.
- tuukkah 7y agothing { 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/objectidentification.htm#sec-Node-Interface https://facebook.github.io/relay/graphql/objectidentificatio...
- sbr464 7y agoI agree, and don't mind, We've just decided to add in both fields thing_id & thing, for parsing convenience.
- tuukkah 7y agoI 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.
- deleted 7y ago[deleted]
- mpnally 7y agoIf 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"