RESTful web services

What package(s) may I use to build RESTful web services? Is there any tutorial around?

5 Likes

If you are using Julia 0.7-DEV, you can run following sample.
https://github.com/wookay/Bukdu.jl/blob/sevenstars/examples/api/endpoint.jl

Required packages are HTTP.jl and Bukdu.jl:
https://github.com/wookay/Bukdu.jl/tree/sevenstars

it just provide very basic stuff.
any issue are welcome. thanks.

You can also build REST or other types of APIs directly with HTTP.jl. Once example of how to do this is Joseki. I think you can also do the same with @anon67531922ā€™s Pages. In the past people did this with Mux but I wouldnā€™t recommend it going forward.

What problems do you see with Mux? It would still be the first package Iā€™d generally reach for if I were to build a web server thingy. Is it just the fact that it seems unmaintained at the moment?

I think the main issue is that itā€™s unmaintained, and most of the web ecosystem is moving towards the new HTTP.jl which provides a lot of the functionality thatā€™s built into Mux.

The approach that Mux takes is also not one that I prefer. It works really well for people who want to spin up a basic webserver on their system, but lots of common tasks require mucking around in the Mux internals. For example, take a look at the DiffEqOnline API. @ChrisRackauckas and I needed to add CORS headers to all the responses which ended up being quite messy (although maybe thereā€™s a better way to do it in Mux). We also needed custom error handling which required similar mucking around. I prefer the approach that Express takes ā€“ you construct a server by creating a middleware stack and adding routes from the ground up.

Thanks for all the ideas. Now I have a lot to play with :slight_smile:

I imagine that weā€™re not very mature in this area yet. A simple microservices framework similar to Python Flask would be great.

Alternatively, I also thought about exposing APIā€™s via ZMQ and do the web tier in other languages but it would be much nicer to work in the same environment.

While itā€™s approach may not be for universally liked, Mux is very much not unmaintained. There are many production servers running on Mux.

Every time this question comes up, I suggest JuliaWebAPI.jl (so Iā€™m clearly biased), but IMO nothing comes close to the easy and flexibility of this package to deploy REST services. It is built on top of Mux, which is built on top of HTTPServer.jl

Regards

Avik

nothing comes close to the easy and flexibility of this package to deploy REST services.

Them are fightinā€™ words! :cowboy_hat_face:

Hehe. Every time this subject comes up, you recommend JuliaWebAPI.jl (for obvious reasons) and I recommend Pages.jl (for obvious reasons). Pages.jl has also been deployed to Azure for production purposes and will be used more heavily soon, so I appreciate eyes looking at it to help make it better :slight_smile:

Although Iā€™m sure JuliaWebAPI.jl is built on more solid web best practices, I think it is a bit too much to say it is the easiest. I tend to make every mistake in the book, which makes me a good teacher (because I can relate to suffering students :sweat_smile:) and Pages.jl was built to be simple.

julia> using Pages; @async Pages.start()
Listening on 0.0.0.0:8000...
julia> Endpoint("/hello") do request::Request
       "Hello world"
       end
Endpoint created at /hello.

(Note: You can add Endpoints any time, even after the server is started.)

One thing I like about this is you can get started without knowing anything about web development. You donā€™t even need to know the difference between get and post. The syntax is pretty self explanatory I think.

As a bonus, there is built in WebSocket functionality including callbacks so you can have Julia and JavaScript talking to each other.

Check out the Plotly example. You can send plots from Julia to the browser in real-time from the REPL (with no page reloading). Iā€™m hoping to add a lot more interactive plotting capability.

I need to tag a new version, so recommend Pkg.checkout("Pages") to get the master branch.

In any case, I am happy to see interest in web development and Julia. The more we work together, the better for everyone. Bukdu.jl looks cool and everyone should keep an eye on Charlotte.jl. That is a very exciting project. And for more serious web backends, in addition to JuliaWebAPI.jl, you should also check out Genie.jl.

Good luck! :blush:

4 Likes

No worries, guys. Iā€™m trying both and will submit some feedbacks to your Github repo.

Zero commits in the last 14 months + 8 open pull requests (for Mux.jl) doesnā€™t exactly scream maintained. Just sayinā€™ :wink:

I think thatā€™s is unfair. As Iā€™ve said before, many production services depend on Mux, including Juliabox, used daily by thousands of users. If thatā€™s not a sign of a mature library, I donā€™t know what is.

I donā€™t think anyoneā€™s questioned whether Mux.jl is mature or not widely used; the original question was what package to use for restful web services. Between a package that hasnā€™t been actively developed in a long time (Mux.jl) and a package that provides similar functionality and is actively developed/maintained (HTTP.jl), Iā€™m just saying I know what Iā€™d target if I needed to setup a restful web service. HTTP.jl is already 0.7/1.0 ready and provides a much cleaner middleware layering stack for extensible servers.

1 Like

A word of caution to the OP:
As the README.md for HTTP.jl says ā€œThe package is new and not yet tested in production systems.ā€.
If you need something field-proven right now. HTTP.jl is not it.
If youā€™re aiming to deploy a production system after the Julia 1.0 release, HTTP.jl is certainly under active development and heading towards being stable soon after the Julia 1.0 release.
If you are willing to take a leap and try HTTP.jl now, thatā€™s great!, and either @quinnj or I will try to help with any issues you encounter.

We should also update the docs, since there is at least a handful of cases where HTTP.jl is being used in production (that Iā€™m aware of at least).

@samoconnor & @quinnj - thanks for offering help.

May I also suggest improving the docs with complete examples about how to build a web service properly?

The README file has trivial examples with HTTP.listen() but I would want to know how to use the router or handler, how to create a filter and pass information from one to the next, how to start/stop the server, etc. I donā€™t think Iā€™m the only one :slight_smile:

6 Likes

Iā€™ve used Pages.jl to run a tie a Julia simulation into a web front-end that allows the user to change the parameters and visualise the results - itā€™s going great so far (thanks Eric!). Iā€™d like to send a progress report back to the user, and I just canā€™t get my head around Pagesā€™ code for this. I merely want to send a bit of text back from a loop within Julia that has been triggered by a POST endpoint (and only to the browser that submitted the POST). I canā€™t figure out if I need the Pages.js functionality - it seems overkill and I donā€™t really understand it yet. Thereā€™s a bit in the examples/blank.html page that seems ideal, but when I try to run that example I get ā€œFirefox canā€™t establish a connection to the server at ws://localhost:8000/examples/blankā€ - and foolishly I canā€™t understand how the simulation will know an ā€˜idā€™ to send the message to anyway.
Sorry for the basic question (Iā€™m no web developer, obviously!) - any help greatly appreciated.
-Gavin

Hi @macroscian :wave:

Iā€™m glad to hear youā€™ve made some progress using Pages.jl and similarly sorry youā€™re having some difficulties. Do you mind opening an issue on Github and we can sort it over there? :blush:

Here is the link to submit a new issue: https://github.com/EricForgy/Pages.jl/issues

1 Like

If anyone is interested, here is the issue: Websocket help Ā· Issue #20 Ā· EricForgy/Pages.jl Ā· GitHub

I simply exposed the client id as Pages.id accessable from JS so you can include that in your POST and use Pages.message from the Julia side with the client id :blush:

1 Like

Hi @anon67531922 just to let you know that the paper we used your package in has eventually been published, and youā€™re duly acknowledged:
https://www.cell.com/cell/fulltext/S0092-8674(20)30153-7
Thanks for your help on this.

4 Likes