3 ms·

Is it just me, or do these "API contracts and type safety guarantees" all call back to SOAP?

brightball 3y ago
WSDL
nine_k 3y ago
The core idea of SOAP was good. The ability to generate client and server code stubs from a single declarative file was great. I worked with SOAP extensively in early 2000s. The problem that killed SOAP, to my mind, was growing complexity that eventually started to outweigh the benefits of the protocol. Not every implementation supported every new complication that, say, MS kept inventing, it hurt interoperability. I think a modern sort-of-replacement for the SOAP's use case is GRPC. It eschews the heavyweight XML and tries to keep things simple, while staying reasonably typesafe, declarative, discoverable, and extendable.
- chrisweekly 3y ago
  Speaking from painful experience, gRPC is an absolutely terrible choice for client-server interactions. Google (its creator) discourages its use except for server-to-server, and Improbable labs' grpc-web library is handcuffed to brittle and rapidly-aging web tooling.
  - nine_k 3y ago
    GRPC is compact; in some cases it's important. What would you suggest, beyond the standard "ReST" and GraphQL, with OpenAPI as a declarative description?
    - rattray 3y ago
      For a compact message format being sent to browsers, you might look at messagepack, eg with https://github.com/msgpack/msgpack-javascript https://github.com/msgpack/msgpack-javascript – it's essentially binary JSON, so it'd be compatible with OpenAPI specs. I think the ser/des is slower than JSON in most browsers, but the message format is smaller. Oftentimes, using a query parameter like `?exclude[]=…` or `?include[]=…` or similar to say "only get me these response fields, not the whole object" can be useful for this too (and then you still get JSON back).
anttiviljami 3y ago
Yes! SOAP wsdl, but json
jjice 3y ago
Yes it's an interesting trend. I integrate with a good handful of systems in my current work and the most important ones we integrate with are SOAP based. The concepts behind a WSDL are great in theory, but they end up incorrect or unmaintained in practice (at least with the systems I integrate with). There's something freeing and flexible about a plain REST API that makes developing your own wrapper nice and simple, but if all communication is between internal systems, a contract based approach seems great.
cryptonector 3y ago
All the way back to Apollo Domain.

WSDL

The core idea of SOAP was good. The ability to generate client and server code stubs from a single declarative file was great. I worked with SOAP extensively in early 2000s. The problem that killed SOAP, to my mind, was growing complexity that eventually started to outweigh the benefits of the protocol. Not every implementation supported every new complication that, say, MS kept inventing, it hurt interoperability. I think a modern sort-of-replacement for the SOAP's use case is GRPC. It eschews the heavyweight XML and tries to keep things simple, while staying reasonably typesafe, declarative, discoverable, and extendable.

chrisweekly 3y ago
Speaking from painful experience, gRPC is an absolutely terrible choice for client-server interactions. Google (its creator) discourages its use except for server-to-server, and Improbable labs' grpc-web library is handcuffed to brittle and rapidly-aging web tooling.
- nine_k 3y ago
  GRPC is compact; in some cases it's important. What would you suggest, beyond the standard "ReST" and GraphQL, with OpenAPI as a declarative description?
  - rattray 3y ago
    For a compact message format being sent to browsers, you might look at messagepack, eg with https://github.com/msgpack/msgpack-javascript https://github.com/msgpack/msgpack-javascript – it's essentially binary JSON, so it'd be compatible with OpenAPI specs. I think the ser/des is slower than JSON in most browsers, but the message format is smaller. Oftentimes, using a query parameter like `?exclude[]=…` or `?include[]=…` or similar to say "only get me these response fields, not the whole object" can be useful for this too (and then you still get JSON back).

anttiviljami 3y ago

Yes! SOAP wsdl, but json

jjice 3y ago

Yes it's an interesting trend. I integrate with a good handful of systems in my current work and the most important ones we integrate with are SOAP based. The concepts behind a WSDL are great in theory, but they end up incorrect or unmaintained in practice (at least with the systems I integrate with). There's something freeing and flexible about a plain REST API that makes developing your own wrapper nice and simple, but if all communication is between internal systems, a contract based approach seems great.

cryptonector 3y ago

All the way back to Apollo Domain.