
Standards.REST: A Collection of HTTP/REST API Standards and Specs - geezerjay
http://standards.rest/
======
somada141
I'm a little surprised I didn't see the JSON:API spec [1] on there (no
affiliation). While by no means a silver bullet my team has adopted it for
both internal and public APIs and our clients have been quite happy having a
standardised API like that.

In addition it is fairly-well supported by community packages (at least in
Pythonland, e.g., marshmallow-jsonapi [2]) so it fit quite nicely in our stack
while we could incrementally come up with v2 APIs that implement it.

Lastly, the spec does a semi-decent job, again no silver-bullet, of defining
more advanced API features like filtering, sorting, field-selection, etc in a
way that brings a lot of the GraphQL perks into REST.

[1] [https://jsonapi.org/](https://jsonapi.org/) [2]
[https://github.com/marshmallow-code/marshmallow-
jsonapi](https://github.com/marshmallow-code/marshmallow-jsonapi)

~~~
rocketpastsix
The idea originally was just to show RFC's but I think we can start expanding
the project now.

~~~
somada141
Ah sorry didn't realise it was supposed to be limited to RFCs. I suppose
JSON:API would fit the `A collection of standards and specifications` title
:).

------
jypepin
This doesn't seem like it's much helpful. If someone is building a new API and
want a list of standard/best practices to follow, something like OpenAPI[0]
would be much more helpful.

Here, I'm not sure what one would do with a list of RFCs?

[0] [https://swagger.io/resources/open-
api/](https://swagger.io/resources/open-api/)

~~~
M2Ys4U
The last time I looked at Open API it was really hard to model a proper REST
(HATEOAS) API

~~~
treve
Still is

------
rubyn00bie
Hmmm... not to be a curmudgeon, but will this help much? Or like what is the
intended purpose of this, awareness? Why were these RFCs chosen? I feel like
the majority of folks who would take interest in this would already be
browsing RFCs. Additionally, this would be more useful it contained (I didn’t
see any from my phone) links to example implementations or discussions about
the RFC.

I appreciate the work, and thought so far, I was just super stoked for like
“MOAR infos,” and then didn’t really get any so I’m a bit disappointed ;_; or
maybe I’m just missing something like usual?

~~~
exfed
I think the take-away is that the Web (with a capital W), even though it's
what all the cool kids are doing these days, is really just a collection of
real actual standards established by real actual standards bodies, run by real
actual Engineers. There are plenty of folks out there who don't give the Web
much credence, and would rather shout at those kids to just get off their
lawn.

Maybe I'm over-stating the value, but it's good to remember that, as software
and automation becomes more ubiquitous, good standards and good engineering
are going to get more and more important.

------
the_arun
Here are some links that are useful:

1\. [https://github.com/Microsoft/api-
guidelines/blob/master/Guid...](https://github.com/Microsoft/api-
guidelines/blob/master/Guidelines.md)

2\.
[https://cloud.google.com/apis/design/](https://cloud.google.com/apis/design/)

3\. [https://mattgemmell.com/api-design/](https://mattgemmell.com/api-design/)

4\. Video from Jim Webber -
[https://www.youtube.com/watch?v=aQVSzMV8DWc](https://www.youtube.com/watch?v=aQVSzMV8DWc)

------
Malic
I kinda wish the domain was "rest.standards" instead to set the pattern of
"*.standards" would be where you found such things.

~~~
pgwhalen
Perhaps you should make that URL scheme a standard?

------
nwatson
No HATEOAS?
[https://en.wikipedia.org/wiki/HATEOAS](https://en.wikipedia.org/wiki/HATEOAS)

I don't think full-on HATEOAS is practical, and blog
([https://jeffknupp.com/blog/2014/06/03/why-i-hate-
hateoas/](https://jeffknupp.com/blog/2014/06/03/why-i-hate-hateoas/)) says it
well: "When designing a hypermedia API [per HATEOAS standards], you're really
designing for a client that does not, and will never, exist." There are some
good ideas there though.

~~~
jmull
I'm not sure the criticism in that blog has much to with anything. HATEOAS is
about an approach to managing application state, not self-documenting APIs.

I suppose it still gets at the big problem with a restful approach: nobody
really gets it.

(Personally, I think there are some great ideas in that dissertation, but
HATEOAS isn't one of them. At least as far as I can tell.)

~~~
naasking
HATEOAS is a good idea as well. It formalizes an idiom for schema upgrade and
discovery.

------
dmitriid
These two resources are a much much much bigger help:

\- HTTP decision diagram (click around, every section is explained with links
to specs) [https://github.com/for-GET/http-decision-
diagram/blob/master...](https://github.com/for-GET/http-decision-
diagram/blob/master/doc/README.md)

\- Know your HTTP well: [https://github.com/for-GET/know-your-http-
well](https://github.com/for-GET/know-your-http-well)

------
mxschumacher
Zalando's REST API resource is quite helpful:
[https://opensource.zalando.com/restful-api-
guidelines/#intro...](https://opensource.zalando.com/restful-api-
guidelines/#introduction)

------
hughes
> "The .rest gTLD will provide an online zone for restaurants and corollary
> entities..." [1]

As interesting and useful as this may be, it seems to be a misuse of the
chosen TLD.

[1] [https://icannwiki.org/.rest](https://icannwiki.org/.rest)

Edit: looks like I was wrong about this one!

~~~
afarrell
This begs the question: Has anyone here seen .rest used in the restaurant
industry?

~~~
1f60c
I have not, but

    
    
      site:rest
    

gives several hits[0]

[0]:
[https://www.startpage.com/do/search?query=site%3Arest](https://www.startpage.com/do/search?query=site%3Arest)

