If we want a non-RESTful (in the strict sense) solution with those particular enterprise features, we have SOAP+WSDL.
Reinventing the wheel and calling it RESTful is non-helpful (because, again, we have a mature infrastructure of tools filling that need in the SOAP+WSDL space, so if we don't need a new approach, it would be more efficient to use them rather than rebuild them, and if we do need a new approach, well, reinventing SOAP isn't it.)
REST does offer solutions to those problems, but these pseudo-REST approaches drop exactly the pieces that address those concerns and replace them with approaches based on the way earlier, pre-REST, systems approached the problem. Which amounts to throwing out the core of REST for no gain over just using the earlier technologies.
SOAP is RPC. It's fundamentally different. REST is not completely undone just because you want validation. Without a schema or DDL, you're still validating but you're doing it in code.
It's fundamentally different than REST, sure. Its not fundamentally different than "REST" that abandons resource-oriented hypermedia.
REST is not completely undone just because you want validation.
REST includes a validation model (indeed, its centered around one.)
It is completely undone when you toss that out and replace it with a different one.
Without a schema or DDL, you're still validating but you're doing it in code.
With a schema or DDL, you are validating in code. It may be code in an external library or tool, but that's just a possibility with any validation model, whether its Schema-based, or Media-type-based (as in REST), or based on something else.
Comments
If we want a non-RESTful (in the strict sense) solution with those particular enterprise features, we have SOAP+WSDL.
Reinventing the wheel and calling it RESTful is non-helpful (because, again, we have a mature infrastructure of tools filling that need in the SOAP+WSDL space, so if we don't need a new approach, it would be more efficient to use them rather than rebuild them, and if we do need a new approach, well, reinventing SOAP isn't it.)
REST does offer solutions to those problems, but these pseudo-REST approaches drop exactly the pieces that address those concerns and replace them with approaches based on the way earlier, pre-REST, systems approached the problem. Which amounts to throwing out the core of REST for no gain over just using the earlier technologies.
SOAP is RPC. It's fundamentally different. REST is not completely undone just because you want validation. Without a schema or DDL, you're still validating but you're doing it in code.
Yes.
It's fundamentally different than REST, sure. Its not fundamentally different than "REST" that abandons resource-oriented hypermedia.
REST includes a validation model (indeed, its centered around one.)
It is completely undone when you toss that out and replace it with a different one.
With a schema or DDL, you are validating in code. It may be code in an external library or tool, but that's just a possibility with any validation model, whether its Schema-based, or Media-type-based (as in REST), or based on something else.
A schema allows for declarative validation and allows it to be defined once and once per consumer.
A well-defined media-type does much the same thing and is what REST is centered on.
An API based on HTTP and schemas rather than media types for content definition/validation is more like SOAP than REST.
OTOH, an API based on resource-oriented hypermedia could incidentally use media types that are defined in terms of schemas, and still be REST.