Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hypermedia / HATEOAS #23

Open
AlexZeitler opened this issue Jan 13, 2020 · 6 comments
Open

Hypermedia / HATEOAS #23

AlexZeitler opened this issue Jan 13, 2020 · 6 comments
Labels
discuss Topics for open discussion

Comments

@AlexZeitler
Copy link

AlexZeitler commented Jan 13, 2020

While HTTP APIs are very popular today, REST, Hypermedia and HATEOAS - while offering many great opportunities for API developers and consumers - never got broadly adopted.

Having build Hypermedia/HATEOAS APIs in .NET and Node.js with several customers one of the biggest issues I experienced was that there was no common way to create Hypermedia across frameworks/libraries even on the same platform.

Having native support for common Hypermedia formats like Siren, Ion, HAL, CJ and HTTP Problem Details should make it easier for developers to build truly Restful APIs and gain benefits with almost no efforts.

Phil Sturgeon recently has written an great sum up what web frameworks should support today to build great APIs.

A while a go I've implemented a modular set of libraries to create HTTP Problem Details (RFC 7807) which consists of two HTTP framework agnostic libraries:

For use with e.g. express, there exists express-http-problem-details - another library, which is a express middleware that handles errors in requests and returns HTTP Problem documents created using the convention defined in http-problem-details-mapper.

I think there should be common support for creation of Hypermedia Documents based on Hypermedia factors so that folks who invent their own Hypermedia type could easily build support for every web framework.

@wesleytodd
Copy link
Member

I am currently squatting the module rfc7807-json which I was planning on doing something similar with 😄. I wont be giving up the name or merging together with a typescript project, but I agree there is some opportunity for some similar RFC's to be implemented in more opinionated frameworks (hopefully sharing some work). That said, I don't think this would be something provided by node core.

I don't really have much to say on the rest other than: I think those spec's failed because they were bad for one reason or another. I know for sure that when one company I worked at tried HAL it was more unhelpful than anything else.

@wesleytodd wesleytodd added the discuss Topics for open discussion label Jan 14, 2020
@wesleytodd wesleytodd changed the title agenda: Hypermedia / HATEOAS Hypermedia / HATEOAS Jan 14, 2020
@ghermeto
Copy link
Member

@jasnell also has a module that implements RFC7807 called http-problem.

I really don't know about hypermedia, but I'm in favor to recommend use of RFC7807 moving forward.

@jasnell
Copy link
Member

jasnell commented Jan 27, 2020

My module could use a look-see to make sure it's still good but happy to do so if it's useful for folks!

@wesleytodd
Copy link
Member

Not to co-opt the discussion, but @jasnell do you know what the process would be to make revisions to this spec? While I like it in general, I think it is hard to use for many use cases and I would love to discuss and see if there is a path forward for inclusion in an update to the spec. Should I just email the authors? I have never worked on something like this before 😄

@jasnell
Copy link
Member

jasnell commented Jan 27, 2020

@wesleytodd ... we can pick that up in another forum for reaching I can facilitate a conversation with the spec author Mark Nottingham.

@hueniverse
Copy link

hueniverse commented Feb 20, 2020

You can just ping @mnot right here... he is pretty good at following up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Topics for open discussion
Projects
None yet
Development

No branches or pull requests

5 participants