41–50 of 273 posts
cat -> cats,
dog -> dogs,
child -> children,
person -> people,
etc.
It makes my code feel inconsistent too. Sometimes I use more specific typing to resolve this, e.g. PersonList , but I'm not sure that's any better.
Small typo-ish error in the article, emphasis mine: > 401 Unauthorized – This means the user isn’t not authorized to access a resource. Surely that should say that the user isn't not unauthorised?
I'd recommend against using `v1` in the path and prefer content negotiation: GET /resource/1 Accept-Version: ~1.0.2 ... Implementation-wise this ends up with better code (and less code) on the back-end and a reduced number of HTTP routes (which should represent the entities and be maintained). The pain of REST is that there's very little in terms of "correct" as we don't have a formal specification of the semantics.…
I'd recommend the opposite, as with a versioned URL you can very easily route stuff to different machines by simple URL inspection and have a very clean separation between versions.
Media-type versioning is useful for supporting different data types/representations of the same resource.
URL versioning is useful for versioning resources themselves and their behavior/business logic.
But I have missed feelings about graphql. I wish they didn’t invent a new language, it was just json. I’ve encountered so many little bugs because graphql parsing is different between different servers.
Ideas of graphql are great, implementation seems over complicated.
REST is much easier to grok.
Earlier quoted context omitted.
> All things that GraphQL claims to do can be implemented in RESTful services easily. How do you easily write an endpoint that can either return a comment, a comment with its children, a comment with its corresponding story, with a strongly typed schema (ie. no optional children or story whatever the query is)?
like i said, specify what you want in the query params or in the request body
Small typo-ish error in the article, emphasis mine: > 401 Unauthorized – This means the user isn’t not authorized to access a resource. Surely that should say that the user isn't not unauthorised?
401 is unauthenticated (not logged in).
Very important difference for clients handling authentication state.
All these "best practices" are exactly why I embraced GraphQL quickly and flushed "REST" down the toilets for big projects (http+json is fine for small ones, since no lib overhead). GraphQL is unashamedly the new SOAP. I.e. we have a spec, not a series of "best practices" thus endless architectural debates where people are shamed for 'doing it the wrong way' online. - Accept and respond with JSON: No, why? what if I…
Never understood the hype around GraphQL. You want to know how to halve your performance and responses/s on your service? add graphql. All things that GraphQL claims to do can be implemented in RESTful services easily. If you want specificity in your query fetching, just add query params or put them in the request body If you want schema validations, there are many libraries that help you with that. And if you want d…
With GraphQL, you're just pushing N+1 calls and figuring out the mental contortion needed to support all the graphy-ness from non-graph structures. Most that say GraphQL is the bees-knees must be an FE developer. There's nothing wrong with that, but GraphQL is just NOT as cracked up to be.
I interrupted my reading at 'Accept and respond with JSON' to write this comment, before I skipped over that section and returned to reading the rest. Folks that aren't aware of Webmachine should take a look: https://github.com/webmachine/webmachine The 'Accept' header should determine the response type, but content negotiation is something that few bother to implement. Webmachine does that for you, among other thing…
The only advantage I see is that your clients can choose the format they want to work with, but since the serialization format is just a message format that has no impact on the code, and that most of them have a bijective transformation between them, I don't see the point.
If it feels like a lot of work (Or the added complexity of a moving part, if using the tool you linked) for next to no impact.
Just for a point of reference here is Google’s take on the exact same topic. It has a bit more of a gRPC background but still is very REST friendly by default. https://cloud.google.com/apis/design/resources Also as one of the most common pushbacks people have with gRPC is that everyone generally expects JSON still in 2021 especially in the browser. Not sure if this is super well known or not but gRPC integrates well…
In the given example we work with an Article domain. Where there are Comments.
Fine and totally fair.
But how would you design your object graph from the bottom up?
Articles and Comments is a fairly simple example.
Imagine a Transaction in bank domain context.
Would you have an endpoint like so?
transactions/:id/acoount/:id
Or perhaps
transactions/:id account/:id/transactions
Whatever you pick you must find a way for transactions and accounts to work together on a design level, which will impact how you potentially serve services and how you deploy them.
Is an account and a transaction part of the same domain and service?
It's hard to design proper REST apis because although it's easy to dish out cool looking routes, it might be a lot harder to actually design your systems based on those routes.