5 ms·

Nothing about REST prevents strong validation of inputs. If anything, the notion that the ends should pass data using well-defined media types should push one t

Nothing about REST prevents strong validation of inputs. If anything, the notion that the ends should pass data using well-defined media types should push one towards something that can be validated. I don't think "everything chucks application/json around and we have no idea what the JSON represents is in the spirit of REST at all. The set of externally standardized media types is somewhat small. When I worked in real estate, there's not really a standardized set of stuff for that problem domain, and we're pretty much defining our own. And, worse, IMO, we did so badly, because we didn't take the time to lay out a good, well documented specification. Some of the schema languages out there can help with that. (Though I don't think they're a panacea.) Likewise, while I agree with some of the article, protobufs are just not terribly great. The lack of sum types really hampers how you can represent stuff in them. (We had other, more practical issues when we tried to adopt them over JSON in my last org.) But, also, if you want to define application/vnd.foo.bar.baz as "a protocol buf with this definition that contains data representing this" … that can still be as RESTful as JSON. (And, for the XML comparison… JSON is too verbose. XML is just even worse. JSON was a step in the right direction.)

taeric 6y ago
I don't really disagree. But I have yet to see a schema system for JSON that isn't just a crappy version of what XML can do. Similarly, most ways of representing services turn into bike shedding on how to map to HTTP. I will also add that as soon as you think you need complicated models at the API level, you are almost certainly setting a path to problems. Yes, it is possible to come up with a place where sum types will make sense. In most cases, though, you are better representing a flat set of data, and let a validation layer move things into distinct types, if you really need it. I view this as everyone wanting a programming language where you control AST constructs. Sounds great, but working with raw text/data at a layer above will almost certainly be easier. And you can use a compiler/evaluator to get to things you can manipulate at that layer. (Similarly, this idea that files are the bane of computer. In stark contrast to my always just wanting a file that represents whatever I am wanting to move from one place to another. However I want to make that happen.)

taeric 6y ago

I don't really disagree. But I have yet to see a schema system for JSON that isn't just a crappy version of what XML can do. Similarly, most ways of representing services turn into bike shedding on how to map to HTTP. I will also add that as soon as you think you need complicated models at the API level, you are almost certainly setting a path to problems. Yes, it is possible to come up with a place where sum types will make sense. In most cases, though, you are better representing a flat set of data, and let a validation layer move things into distinct types, if you really need it. I view this as everyone wanting a programming language where you control AST constructs. Sounds great, but working with raw text/data at a layer above will almost certainly be easier. And you can use a compiler/evaluator to get to things you can manipulate at that layer. (Similarly, this idea that files are the bane of computer. In stark contrast to my always just wanting a file that represents whatever I am wanting to move from one place to another. However I want to make that happen.)