fehguy

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.

Going to 141 chars would solve all their problems imho

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.

Moved from the swagger core project which had language specific details.

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

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.

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.

very cool tech behind this--html5 fragments, websockets.

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.

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.

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.

As a subprotocol, it leverages the readability of REST into something much more efficient. Maybe pseudo-REST is a better term

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.

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.

there is node.js... https://github.com/wordnik/swagger-node-express

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

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.

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.

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.

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.

Sounds like the open-sourcing of http://swagger.wordnik.com is well timed and can help with this

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?

super slick

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.

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.

I think there are some possible timing issues with making that a general behavior in the server. 10gen did make it the default behavior on slaves, where the inserts are controlled by the oplog (http://jira.mongodb.org/browse/SERVER-1646).

For us, our DB abstraction layer made this behavior so simple to add that we didn't make much fuss about it.

You could run mysql with the memory storage engine and with our schema--which would require multiple outer joins OR subqueries--mongodb will still be much faster. So I think it's much more than an fsync issue.

Storing objects with any sort of hierarchy is so simple with Mongo that the LOC required to do so is ridiculously smaller. Querying them is also faster--for instance we can filter in our dictionary data with queries like {"entry.definitions.relatedWords":"cat"} instead of making some huge join and filtering against that.

Querying before the writes solved a lot of problems. It gets the object in the working RAM set. When doing an update, the database gets LOCKED when the statement hits the server--that means if your document is not in memory, you have to wait while it gets looked up. This was an easy, easy win for us.

Regarding the corruption, I got an "invalido BSON object" or something on repair, which tells me some object was only partially flushed to disk when the DAS went down. The slave actually worked fine for simple lookups by ID, but there was some issue with the index and I was unable to run filters against it. Luckily the huge collections are only accessed via unique identifier, so this wasn't a huge issue.

Hi Christopher, glad you like Wordnik. Do you mean you couldn't find this?

http://www.wordnik.com/words/monad