fehguy
Re:Problems with Swagger
on Tuesday April 04, 2017 @11:18PM (#14039401)
Isn't it more work to write tests than code? Not sure that's the best argument against a technology.
You can easily hang yourself many different ways. The idea with Swagger includes some rules, which is what makes it useful. If you don't want that, then why use it?
It would be nice if you didn't have to write HTML to write a web page, but that's a constraint that has pretty well known benefits to end users.
Re:Coming soon: express even more in 140 characters
on Tuesday May 24, 2016 @10:28PM (#11767275)
Going to 141 chars would solve all their problems imho
Re:Amazon API Gateway – Build and Run Scalable Application Backends
on Thursday July 09, 2015 @08:52PM (#9861726)
Looks great vlad. It is true, this was the first known visual swagger editor and was a very helpful project (also open sourced). The Apigee folks went on to build the current version, a separate effort from the swagger-ui.
Re:Swagger spec for rest apis
on Thursday March 20, 2014 @09:42PM (#7440150)
Moved from the swagger core project which had language specific details.
Swagger spec for rest apis
Re:Show HN: Given an API, Generate client libraries in Node, Python, P...
on Saturday January 04, 2014 @01:42AM (#7010271)
https://github.com/wordnik/swagger-codegen
does javascript, scala, java, objective-c, php, python (3), ruby, android, and even flash
Also has the benefit of a commercial backer (https://helloreverb.com) and a real app depending on it
Re:The Fastest Way to Connect to an API with JavaScript
on Thursday July 18, 2013 @12:58PM (#6064880)
swagger-js uses the shred library (https://github.com/automatthew/shred) under the hood so HTTP connections between the browser and nodejs work the same.
The Fastest Way to Connect to an API with JavaScript
Re:Apiary.io – REST tools for API documentation and testing
on Monday July 15, 2013 @03:45PM (#6048098)
Generating a server stub was done long ago, in swagger, which is completely OSS:
https://github.com/wordnik/swagger-codegen#to-build-a-server...
And it's based on an intuitive JSON structure.
Re:Wordnik Uses Online Dictionary Technology for Recommendation Engine
on Wednesday December 05, 2012 @01:51PM (#4877839)
very cool tech behind this--html5 fragments, websockets.
Re:Generating nodejs server from Swagger specification
on Tuesday August 28, 2012 @01:27PM (#4444835)
Technique for interface-driven development for APIs could save a lot of hassle--generate your API description, view it in swagger-ui, generate your client, and finally server stubs. The plumbing is done, the business logic is up to you.
Generating nodejs server from Swagger specification
Re:Introducing SwaggerSocket: A REST over WebSocket Protocol
on Friday April 27, 2012 @12:38PM (#3899853)
Yes, the graph in the blog is just a sample. There will be a detailed post about performance coming, including access from browsers and non-browsers across fast and latent connections. The chattiness of REST across slow connections is one of the biggest advantages to the socket protocol. How the client handles the true async behavior of the sockets (not just via callback in the client!) makes a massive difference in performance.
Re:Introducing SwaggerSocket: A REST over WebSocket Protocol
on Thursday April 26, 2012 @02:24PM (#3895405)
Both browsers and servers need something like SwaggerSocket this--SPDY is a good step but i feel it's more of a "pipelining" solution rather than an async + multiplexing issue.
Re:Introducing SwaggerSocket: A REST over WebSocket Protocol
on Thursday April 26, 2012 @01:56PM (#3895256)
As a subprotocol, it leverages the readability of REST into something much more efficient. Maybe pseudo-REST is a better term
Re:Swagger: A simple, open standard for describing REST APIs with JSON
on Tuesday March 27, 2012 @11:31AM (#3762030)
We tried out enunciate as well. It's good but didn't quite fit our needs...
You can run swagger with the built-in support via swagger-core/swagger-jaxrs. Play 1.4/2.0 support is there as well and a number of folks are creating support for other server frameworks. See the samples for integration:
https://github.com/wordnik/swagger-core/tree/master/samples
But to be honest, you can run the whole system with static files and zero server integration.
The downside of using javadocs is that you need to expose sourcecode/docs.
Re:Swagger: A simple, open standard for describing REST APIs with JSON
on Tuesday March 27, 2012 @01:39AM (#3760193)
I think the biggest difference is that this is a framework, not just a spec, and you can implement the server with the libraries. The google explorer makes it easy to consume google apis, which is great if that's what you're trying to do. If you want others to consume your api, you need a framework to facilitate the schema generation.
Re:Swagger: A simple, open standard for describing REST APIs with JSON
on Monday March 26, 2012 @08:00PM (#3759250)
there is node.js... https://github.com/wordnik/swagger-node-express
Re:With Software, Small is the new Big
on Tuesday March 20, 2012 @11:45PM (#3732997)
We have a common communication interface (swagger) and have developed websocket-based communication between servers using the Atmosphere framework. Yes, HTTP overhead isn't trivial for chatty server communication. Sockets solve that
Re:With Software, Small is the new Big
on Tuesday March 20, 2012 @11:42PM (#3732994)
Yes! For communication this is part of the motivation for developing Swagger. For configuration & monitoring, our Caprica configuration tool keeps all the servers talking to the right services. It's not terribly complicated but not something to overlook. I'll blog about it soon.
Re:With Software, Small is the new Big
on Tuesday March 20, 2012 @11:40PM (#3732986)
Netflix is an example to the opposite.
But it is worth noting that a great model is a hybrid physical/cloud, once you have established predictable, steady load.
Re:With Software, Small is the new Big
on Tuesday March 20, 2012 @11:37PM (#3732979)
And when you need another data center, you shell out major coin. That's what we needed to avoid.
At some point, even your finest physical server has limits. If you can split the work up into smaller pieces that execute in "parallel" fashion, you have a more scalable architecture. This holds true in VMs as well as physical servers. Think map reduce, twitter blender, or nearly any parallel system.
Rope is strong because it has many threads.
Re:With Software, Small is the new Big
on Tuesday March 20, 2012 @11:31PM (#3732952)
There is no question that physical machines are faster than VMs. The main issues are fixed cost, burst capacity, multi-datacenter deployments and linear scaling. That was the main point of the migration. There is nearly zero unused capacity now--that is a very tough thing to achieve with physical machines.
Re:API Integration Pain? Ouch. (HN Survey Results)
on Thursday August 11, 2011 @11:47AM (#2873345)
Sounds like the open-sourcing of http://swagger.wordnik.com is well timed and can help with this
Re:Wordnik's swagger api framework
on Wednesday August 10, 2011 @02:57PM (#2869668)
Creating an easy mechanism for declaring a web service signature AND it's models makes this work. Does this pick up where WADL left off?
Wordnik's swagger api framework
Re:Wordnik Developer
on Tuesday May 31, 2011 @06:39PM (#2604987)
super slick
Re:API docs done right
on Thursday February 10, 2011 @03:04PM (#2203463)
I'm somewhat biased but after looking long and hard for a good rest documentation system, i think this is the right way to do it.
Re:12 Months with MongoDB
on Monday October 25, 2010 @08:45PM (#1832345)
Kinda depends on the use case. Let's say you have a caching layer and update a subtree in your RDBMS. Then you need to go find all values referencing that object and invalidate them. That's potentially a lot of complexity. Of course you could cache only parent objects and fetch the subtree on demand (cache or db). Hello slow.
So I prefer to not use words like "usually" as it truly depends on your application and use case.