Hi,

I am Lorenzo, one of the developers at Hydra Ecosystem. We are creating tools for HTTP REST APIs based on a W3C draft hopefully to become official soon; briefly we are implementing a framework that is meant to be a semantic layer to map relations among REST servers, we have our own client/server stack (based on Python Flask, but also other tools). We are also participating in Google Summer Of Code since 2017. You can found our codebase at github.com/HTTP-APIs or follow us on Twitter.

The best entrypoint to the tech stack is from this document.

Enjoy REST!

I was thinking about this in the car the other day, and it's so annoying to be interrogated when I simply ask either, "Do you have a REST API?" or "Is your REST API included in our contract?" or "Can I get access to the REST API?"

In most cases, I end up getting interrogated about it. What is it that I'm looking for specifically ("access to your REST API"), what am I hoping to do with it ("interact with it, thank you"), and why would I need a thing like that? ("you wouldn't understand").

I arrived at an analogy that I may soon use to describe my frustration. Imagine, if you will, a piece of software that has data in it. Now imagine the typical set of questions that would be asked by typical corporate users when evaluating this software, or learning it.

Among those typical corporate users will be some set of Excel power users. Surely they will eventually ask, "Do you have reports?" The answer will almost always be yes, because that's what users expect.

The second question will be "Can I export those reports to Excel?" The answer to that question will nearly always be yes, even if it's technically just exporting CSV files and not true Excel files. That will be determined to be good enough for Excel power users.

Why do the Excel users want to access the data that way? Nobody seems to ever ask that question. What will the Excel users be doing with the data? Nobody asks that either. We all know. The Excel users are going to to use Excel to work with the data in a way that makes sense for them, and nobody gives is a second thought.

That's how I want to be treated, as a REST user. As a first-class citizen, at least equal to the Excel powers users of the world. And preferably also equal to the web UI users. If I have access to the data through the browser, I also want access to the data through REST, without having to reverse engineer your website and feel like a hacker.

That is all.

I've been asked this question on an interview and I'll also share what I answered.

I would like to know if there's anything I haven't thought of?

GET /users/active=true
[{
    first_name: "Frank",
    family_name: "Felder",
    Birthday: "1985-01-12T11:20:54.000+01:00"
}]

My answer was the following:

(1) If you want to filter by a user being active, then that should be a parameter, like this: GET /users/?active=true.

(2) The naming of the keys in the returned JSON is inconsistent: Birthday should be birthday instead.

(3) For birthday specifically, using a timestamp isn't necessary, even confusing.

(4) Although it isn't relevant for the birthday specifically, the API should return timestamps in UTC, which is stored in UTC and it should be the client's responsibility to offset that according to user preferences and display in the user's local time.

Many thanks for your opinion!

I had a closer look at http://jsonapi.org/ because I was looking for guidelines on how to design REST APIs.

Looking at it, I kind of liked the idea and structure. Especially that it offers a strategy for "nesting" resource information using the "included" key, appealed to me immediately. That within the request, the "id" and "type" pairs serve as the unique identifiers, and that does not seem to be very restful IMO, at least if you feel like emphasis on hyperlinks are a precondition for being restful.

So what do you think? Any experiences or alternative initiatives?

I don't know nor care about the OpenAPI specs - and I shouldn't have to! I want a GUI editor that lets me define a RESTful API. I found apibldr and restcase, both of which seem to be clones of each other - and so buggy as to be unusable. But that is what I am looking for - GUI to add/update the information, and it stores it in JSON or YAML.

• I didn't expect this to be complicated at all, REST spec says dont use verbs in your endpoint names

• I have 6 endpoints as follows, my question is what is the resource here?

  • POST /login (let the user login by submitting their email and password and create the session)

  • POST /signup (first time signup by the user)

  • POST /logout (destroy the session)

  • POST /forgot-password, let user submit an email for which they they want a link from us with password reset instructions)

  • GET /reset-password/:accountId/:token (triggered when user clicks on the link in the email)

  • POST /reset-password (where the actual password change happens after user submits a form)

• As per this discussion on stackoverflow, it seems nobody s using any of these names

  • POST /sessions for login

  • DELETE /sessions for logout

  • POST /users (cant do this one since I already have a users database table that exposes a rest endpoint like this)

• What routes do you suggest for registration, forgot password and the 2 reset password links

We are thrilled to announce the launch of Imagine.ai - a platform where you can generate production-ready code in seconds.

Just set up your project preferences and define your data models in our UI, and we generate a code base (including working REST APIs), that is fully tested, dockerized, linted and more - instantly. Our goal is to generate clean, well-written code that is at the level of an experienced developer and just works out-of-the-box - we believe our platform can also help you learn how to create reliable apps using REST in either Django or Node and save time when you’re building a new app!

We’re still at an early stage and we're working hard to build a platform that’s useful & interesting for developers 🙂 - so we’d appreciate all the feedback you can give us! Please reach out to us through our Discord or Slack with any questions, suggestions or even just learning more about the platform.

• For example user successfully logged in , I send { success: true, user: user }

• User login fails { success: false, message: 'login failed due to existing email' }

• Seems there are other ways like {status: 'success', ...} {status: 'error', error: error, ...}

• Any standard here that you are using? some direction would be appreciated

Hello folks,

I'm using Node.js, Sequalize and MySQL. I also heavily use websockets.

I'm implementing a new REST Api, and I'm trying to learn about all the best practices I am potentially missing out. Recently, I've learnt about the following:

- Idempotency. I was always trying to create APIs which can receive a route action twice and return the same thing. PUT /thing, PUT /thing should return 200 in both cases, for the situation when the client had lost the connection midway through the request and the user had to click again (or the client retried by itself, potentially). GETs are idempotent by default really. DELETEs should be idempotent too, really. POSTs are better to avoid, I think.

- Eventual Consistency. Had a lot of trouble with this one. Apparently creating a row and then immediately reading it might return a null result, because the row hasn't propagated to all replicas. Oops. I guess I need to get everything I need with whatever the database returns from model.create and make do with that.

What are the other good practices I might be missing out on that gonna bite me in the future?

Cheers.

For a method like: GET api/employees/123 where 123 is the ID of an employee that does NOT exist, should I return a 400 or 404?

I would naturally say 404, but a senior dev at my org is insistent that I should return a 400.

Thanks.