Show HN: Swift SOAP Client library through code generation(github.com)
github.com
Show HN: Swift SOAP Client library through code generation
https://github.com/Bouke/Lark
12 comments
Sure it might not make sense to use SOAP for communication between an iOS app and its server-side counterpart. However when writing consumers of an existing SOAP service, for example in an macOS or console application; it might make more sense.
Or server-side swift for that matter...
Good point. Wouldn't you usually do this on a server and then expose a sane api to the ios app? Who consumes SOAP directly in ios?
If anyone is looking for an auto-generated Swift REST client, please give Swagger Codegen [1] a try and the latest master supports both Swift 2.x and 3.
[1]: https://github.com/swagger-api/swagger-codegen
Disclaimer: I'm a top contributor to the project.
[1]: https://github.com/swagger-api/swagger-codegen
Disclaimer: I'm a top contributor to the project.
Why is it called Lark?
SOAP is sometimes referred to as a fat messaging protocol.
Swift is an elegant bird.
A Lark sometimes looks like a fat bird.
Excellent sense of humor, and a really useful library. Thanks a bunch for sharing!Author here, happy to answer any questions.
This looks great - I was working with an old iOS app back when Swift was first released and I wrote an XML parsing library SOLELY because the SOAP support was horrific. I think this will help a lot of people. If you don't mind, I might add a link to your repo from my README just to help point people towards a better approach over manual XML parsing.
Thank you! links are fine of-course; the more the merrier.
This is amazing!
Cool! As the author of a relative new python soap client (zeep) i do feel sorry for you Most wsdl documents dont follow the various specs which will result in a lot of support issues from users
Anyway feel free to contact me if you have any spec related questions
Anyway feel free to contact me if you have any spec related questions
Cool project, seems like a nice improvement over what I've used in the past (suds). Also has some features that Lark currently lacks (SOAP 1.2 / HTTP bindings / rpc / WS-Addressing / WSSE).
From a few years of app dev, at the end of the day it makes everthing a lot more flexible if proxied, even with a tiny facade, because it gives you options and choices when it comes to making changes.