An appeal to simplicity

1

I am concerned that many of the proposals requested do not fix issues with the existing spec or language used to describe it but seek to overcomplicate it to solve personal domain problems. Some problems just aren’t suitable for REST and we should not try and solve them with the base spec.

I’m all for people creating extensions to the json:api and as marked as such but as someone who is trying to be json:api compliant (and creating .NET tools to help others be too), I need the base spec to remain as simple and as close to REST as possible.

The benefit of REST->Hypermedia->json:api is that I do not have to create 100s of pages of spec like I have had to do in the dark RPC past. It doesn’t completely remove the need to describe business objects but I am impressed that I can hand the very minimum of documents to a junior developer (which I must assume the writer of a client would be) and they can work with it, even in a complex domain.

I appreciate there is a desire to reduce the requests into the server with bulk/composite/multi-operations but please can we keep this out of the base specification and content-type.

1 Like
2

I understand the general sentiment, but I think I’d understand it better in the context of specific proposals. Please comment on Github when you think a specific issue is proposing something too broad.

Re bulk/composite/multi-operations: the “Create a resource and it’s related resource” in the same request case has been asked for for so long that I think we really should support it one way or another, but hopefully that way can be simple—and it will certainly be opt-in, as existing servers (obviously) won’t support it.