5 ms·

Back in the day, I was on a yahoo group that had the REST evangelists pushing for how REST maps much better to consumable APIs than the enterprise nonsense that

• andrewf 5y ago
  My favorite WS-* is WS-I, a bunch of guidelines about which versions/subsets of the other standards to use, if you actually want to talk to someone else. (As someone who once had to implement a SOAP server supporting diverse clients, I'll never pass up a chance to get a dig in)
  • function_seven 5y ago
    I remember the time someone told me what the "S" in SOAP stood for. They were clearly pranking me; I refused to believe it. And to this day, nobody will give me the real answer! Whole world is in on this prank, and I've given up trying to find out.
    • wsc981 5y ago
      Obligatory reference “S Stands For Simple: http://harmful.cat-v.org/software/xml/soap/simple http://harmful.cat-v.org/software/xml/soap/simple
    • crispyambulance 5y ago
      The "S" stands for "Complex". It's in the spec.
• discreteevent 5y ago
  > About the only thing that REST over HTTP doesn't provide is sessions, but JWTs and OAuth now handle most of that. I would disagree. HTTP with REST is half a communications protocol. The server can't push data. There are hacks around this but it's not REST as defined by the dissertation. HTTP and REST took sockets and lobotomized them. They work well where you don't need duplex communication but the tragedy is that they have been forced into solutions where they don't fit because lowest common denominator. Think of how much simpler and more flexible a world we would live in if every web server behaved similarly to a message broker, for example. (GraphQL does this, so there is hope).
  • drran 5y ago
    Web sockets are used now to push data to clients. REST+WS is a good combo.
    • regularfry 5y ago
      Yes, and that's REST+..., not REST. If you've got a websocket, you're explicitly making the design choice that client-side application state can live outside the HTTP payload. The key question is this: given a link and some subsequently-received websocket data, could a second client reconstruct the same application state given only a link? If the answer to that is "no", then what you have is not a system which supports HATEOAS. It's just not something people pay attention to once websockets are in the mix. Granted, you might get there by accident, depending on what you're doing with them, but I don't often see that as a design goal.
      • capableweb 5y ago
        HTTP-Kit in Clojure-land has solved this beautifully with a unified interface for handling both WebSocket messages and HTTP requests, so using one function you receive requests/messages that you can act on, and responding to those also have the same interface. http://http-kit.github.io/http-kit/org.httpkit.server.html#var-Channel http://http-kit.github.io/http-kit/org.httpkit.server.html#v... I'm sure similar things exist in other ecosystems too, so it's not impossible.
• matsemann 5y ago
  What I find a bit funny is that everything people write about WS/SOAP would be applicable to GraphQL as well. For instance modifying your comment to: GraphQL services introduced resource addressing over JSON over HTTP that overloaded the equivalent of a URL.
  • jrochkind1 5y ago
    It's always a pendulum. When we're lucky it's a "spiral", where when we swing back to the first pole we do it better than the time before. We're not always lucky.
• bouke 5y ago
  While I agree with your premise that SOAP and WS-* is over-engineered, at the basic (simple SOAP + WSDL) I quite like it. There's a defined contract and you can generate strong-typed clients. I haven't checked in a while, but how is Swagger/OpenAPI in that regard?
  • rswail 5y ago
    I basically loathe code generators in general. :) JSON Schema gives you the equivalent of WSDL. There are various libraries that will take a schema and create the strongly typed objects in the language of your choice. Theoretically, if you have "Code on Demand", your client can ask the server for the code to handle a media type :)
    • bouke 5y ago
      JSON schema describes the format, more like XSD. WSDL is a lot more with definitions of operations, bindings etc.
      • morelisp 5y ago
        REST's fundamental pitch is that for a large class of problems, a good format solves problems more easily than a rich set of operations.
      • brabel 5y ago
        Things like grpc and GraphQL seem to be the descendants of SOAP/WSDL. GraphQL is quite nice as it kind of has the best of both worlds: a strongly typed schema for data and operations, while being fairly close to a simple JSON/HTTP API.
• lmm 5y ago
  Funnily enough I've found the opposite to be true nowadays. When someone offers a WS-* API all you need is the URL of the WSDL and you can start calling it, from whatever language and framework you like. When someone offers a "REST" API you have to spend hours just figuring out what specific stack of stuff they've actually done.
  • toyg 5y ago
    > from whatever language and framework you like Eh, not really. Python SOAP clients are bad and have always been. In reality, SOAP works well only when using platforms sold by commercial vendors, who invested heavily in producing tools for it in an attempt to generate lock-in for their tools. Which means interop issues between platforms, for anything beyond the trivial case, are rife. Whereas REST is so basic that you literally need nothing more than a standard HTTP client (and a JSON parser, these days; back then it would be some hand-rolled XML or even just encoded form-like data).
    • poetaster 5y ago
      Import suds, ditto.
    • ldiracdelta 5y ago
      One of my favorite tricks with REST is sending a complete, bug-reproduction to a vendor as a simple one-line curl command. No arguing back and forth, just tell me when this curl command works properly.
      • 89vision 5y ago
        Not a SOAP advocate by any means, but there's nothing stopping you from sending a curl command with an xml payload to a soap endpoint
        • ldiracdelta 5y ago
          Spose you're right, but I've never tickled a SOAP interface with curl. I fire up a python script when I need to do even the most basic interaction with a SOAP endpoint because, as Dustin Hoffman says in Hook, "Brace yourself lad, because this is really going to hurt."
• pjc50 5y ago
  > everything defined up front between parties, out of band and then the enterprise companies started selling "tooling" to over-engineer and "manage" this nonsense. This pattern has come up again and again. There's a centralized, orderly, Le Corbusier-style planned system. Everyone hates it and avoids using it in favor of a ramshackle schema-less system re-purposed from something else, which has no other advantages other than actually working. See e.g.: circuit-switched networks, guaranteed QoS systems, centralised PKI, the more esoteric parts of XML vs the simplicity of JSON, one-directional hypertext, and the Internet itself vs telcos.
  • jiggawatts 5y ago
    I'm an "infrastructure guy" that has just spent the better part of the last 8 hours of my working day talking to a developer trying to stand up some microservices, or whatever the kids are calling it these days. Every few minutes, they started a sentence with "I just want to...", which I now mentally translate to "... ignore everything like security, reliability, or anything else that doesn't get me a checkbox tick for my assigned task." Their "REST" API? It uses a HTTP GET to post a response, using an intermediate -- unauthenticated -- storage blob to stage the data. "It worked in dev" came the reply to my probing questions. Look, back in the "horrible old days of WS-*", when I still used to wear a developer hat, I could crack open Visual Studio in the morning and simply add a web service dependency to my project. In a matter of milliseconds -- seconds at worst -- it would automatically cough up a C# client for whatever it is that I wanted to talk to, and I could immediately start coding some actual business logic. Today I watched a grown man type in the boilerplate code that the machine used to generate for me. Apparently, this is better because it is "simple". So simple that a programmer using HTTP GET for posting a reply can understand it.
    • twic 5y ago
      Schema languages for "REST" exist (OpenAPI, RAML), and many people use them, but they certainly haven't taken off to the extent that WSDL did. I find that odd. The new hotness is gRPC, which is based on protocol buffers, which uses an out-of-band schema file (you can do a certain amount with protobufs without a schema file, but nothing very useful). People appear to be happily adopting that, and aren't complaining about the need for a schema.
• fieldcny 5y ago
  You needed the tooling because the specs were so complicated and the output so verbose.