Django REST framework 3.6 released | Hacker News Reader

Django REST framework 3.6 released

django-rest-framework.org

90 pointstomchristie8 comments

I have been really impressed by the quality of the releases lately. It has been interesting watching the changes after Tom Christie managed to become full time on it [0] (and the successful Kickstarter campaign [1]).

I would love to see this sort of funding become more common place.

[0]: https://fund.django-rest-framework.org/topics/funding/

[1]: https://www.kickstarter.com/projects/tomchristie/django-rest...

Most heard feedback we get about our DRF APIs is about documentation. For us API devs the dilemma is how to write the docs, where to publish, keep in sync, test and so on. Now with 3.6, there's only one place and it's with the code. Granted, this won't solve our dilemma completely (we still need to write the docs).

Automatic JS client should come in handy as well. I've been toying an idea about automatic integration tests that could exercise the API externally and keep an eye out for schema changes.

DRF is an important product in Django realm. If you haven't already, take a look at their funding options: https://fund.django-rest-framework.org/topics/funding/

What does "new JavaScript client library" mean in the context of front-end libraries like React?

A DRF API + React stack seems like a good combo so I've been looking into that workflow.

I haven't looked too deeply, but it appears to be an API interaction layer. So if React is your V in MVC, this is the M.

The "client library" being referred to is an autogenerated API client, like https://github.com/swagger-api/swagger-js.

Recent DRF releases have been building the CoreAPI schema definition format, which is a generic schema language like OpenAPI (nee Swagger) or API Blueprint.

The other headline DRF feature (API docs) also builds on the CoreAPI schema.

If you prefer existing standards, you can map your DRF API to Swagger using https://github.com/marcgibbons/django-rest-swagger/, and then use swagger-js (or swagger-codegen) to generate client implementations -- though the django-rest-swagger project is currently partially broken due to having migrated to CoreAPI before the latter obtained feature-parity with Swagger; the 0.3 version is more full-featured.

To be precise I'd call it a "dynamic API client". The codebase doesn't change, you read the schema and corresponding actions become available on the client.

There are also "autogenerated API clients", where the API code is templated, based on the API schema.

(I think the swagger-js client also falls into the "dynamic" category, tho most other language implementations based on swagger fall into the templated "autogenerated" category.)

And, yup, working towards bring Core API up to feature parity with Swagger, so that you can fully interoperate with everything that the Swagger ecosystem already provides.

Just want to add that swagger-js is a "dynamic" API client, which means it will load the OpenAPI/Swagger spec [1] during runtime.

If you prefer static API clients/SDKs, please try Swagger Codegen [2] (free, open-source) instead, which supports 30+ API clients and 20+ server stubs as well as API documentations.

[1] https://github.com/OAI/OpenAPI-Specification [2] https://github.com/swagger-api/swagger-codegen

Disclosure: I'm a top contributor to Swagger Codegen.

They describe what it means later in the page [1]:

> The JavaScript client library allows you to load an API schema, and then interact with that API at an application layer interface, rather than constructing fetch requests explicitly.

It looks like it generates a JS library that makes it easy to use the same resource names in your JS as Django without having to write route handlers by hand. In their example, it looks like they list projects by calling

    client.action(schema, ['projects', 'list']).then(...)

[1]: http://www.django-rest-framework.org/topics/3.6-announcement...

Reply on news.ycombinator.com