221–230 of 273 posts
Earlier quoted context omitted.
I'm only aware of SQL Server (2016), Oracle and MariaDB supporting temporal tables, and... having dived in to them, they can certainly add some complexity to your data and queries. Would be happy to learn of more - had to do some digging on this in late 2019 for a PostgreSQL project, but there's nothing native or 'standard' for pg at that point in time.
It's in progress: https://commitfest.postgresql.org/32/2316/
This article doesn't mention linking at all, which is at the heart of REST. Without links, it isn't REST , and most of the suggestions don't have anything to do with REST per se . Most of it is just standard JSON-over-HTTP stuff that's implemented in a variety of frameworks and libraries. EDIT: To be clear, I don't particularly care if an API is "RESTful" or not, as long as it's well-designed and documented, but I th…
> This article doesn't mention linking at all, which is at the heart of REST. Please, just don't do it . Yes, I read the dissertation. It's just not a good idea, it has never given me any practical use whatsoever and has always made dealing with the API more annoying. > Most of it is just standard JSON-over-HTTP stuff that's implemented in a variety of frameworks and libraries. Yes, and we call that REST or RESTful a…
Never overcomplicate things. Never add metadata if you don't have to. Just K.I.S.S
Earlier quoted context omitted.
I assume GP means ISO8601 Date Time https://en.wikipedia.org/wiki/ISO_8601 . Default behavior of javascript date json serialization > JSON.stringify(new Date()) '"2021-02-22T20:34:53.686Z"'
Then why add the "in UTC" part? ISO 8601 specifies how to designate the time zone.
Earlier quoted context omitted.
Sure, that's why I'm asking whether this is at all common. If the use case is programmatic, then just provide the ability to get an arbitrarily large set atomically (rather than forcing pagination size limits) and the problem goes away. Another thing to consider when paginating via id cursors: if the deleted item is the one your cursor is sitting on, then you no longer have a frame of reference at all. For example, w…
> just provide the ability to get an arbitrarily large set atomically It's difficult to do in most HTTP deployments where we try to limit HTTP response duration. > if the deleted item is the one your cursor is sitting on, then you no longer have a frame of reference at all Not a problem. If your order your results by timestamp and ID, then you provide the timestamp and ID of the last item returned, and take anything…
Most of these best practices forget the hard parts of JSON/REST APIs: - How to handle date and time incl. time zones - JSON has no data type for that - Handling of numbers (JSON only has double, which does not fit most cases) - Defined and parseable error responses (rfc 7807 plus extra fields for details) - Localization - do you send translated texts or just error codes? - How to handle updates? Overwrite every field…
This distinction is important because you can't serialize infinities or NaN, and there's no guarantee the JSON number can be accurately represented as a double. JS likes to pretend that JSON number is interchangeable with Number and this can result in some fun situations when your Infinity becomes null
I guess the point is that JSON has about as much to do with JS as JavaScript has to do with Java.
Earlier quoted context omitted.
> This article doesn't mention linking at all, which is at the heart of REST. Please, just don't do it . Yes, I read the dissertation. It's just not a good idea, it has never given me any practical use whatsoever and has always made dealing with the API more annoying. > Most of it is just standard JSON-over-HTTP stuff that's implemented in a variety of frameworks and libraries. Yes, and we call that REST or RESTful a…
Totally agree. HATEOAS is a PITA. Never overcomplicate things. Never add metadata if you don't have to. Just K.I.S.S
Somehow everyone rushed to implement GraphQL schemas, and no one rushed to implement JSON Schemas for example. And JSON Schemas with the right tools are a much more powerful instrument.
Same goes for linking, and the rest of HATEOAS.
At a company I worked we had an internal tool built for most of this stuff which took a lot of problems with HATEOAS away. Unfortunately, we never opensourced it :(
As usual only CRUD counts, no mention of operations, patch, links, aggregation of calls, ways to document API, token duration, rate limits etc.
Adequate for todo list maybe.
This article doesn't mention linking at all, which is at the heart of REST. Without links, it isn't REST , and most of the suggestions don't have anything to do with REST per se . Most of it is just standard JSON-over-HTTP stuff that's implemented in a variety of frameworks and libraries. EDIT: To be clear, I don't particularly care if an API is "RESTful" or not, as long as it's well-designed and documented, but I th…
With only links, you don't know semantics and inputs. The benefits are next to 0, and effects on the maintenance are non trivial.
Earlier quoted context omitted.
> Your first sentence was quite condescending, FYI, not sure if it was meant to be. No, it was not and thank you for flagging that. Is it condescending to assume one is not a web developer if they don't know content negotiation? I thought that was Web 101 and pretty much one of the first things you go through when learning about HTTP, but maybe things have changed as of late. I'm sorry spelunker if my message came of…
I think you can safely assume most people on here are some sort of programmer or at least tech-related. We know about content negotiation it's probably the `Webmachine` `HTTP semantic awareness` `bit-pushing` `HTTP syntax-management` and `mochiweb` that not many people would know. I'm not sure if you're purposefully trying to be sarcastic but even your current comment is kinda scathing.
webmachine is one of the earliest libraries I'm aware of that tried to think carefully about HTTP semantics and structured it's work with restful APIs (or web requests in general) according to an actual diagram that you can see here: https://github.com/basho/webmachine/blob/develop/docs/http-h...
There's an expanded and re-worked version that builds on this here: https://github.com/for-GET/http-decision-diagram/tree/master... (follow the links to system, request etc. to see the reasoning and references for each step)
I’ve also found the Microsoft API guidelines helpful (especially for error handling). https://github.com/microsoft/api-guidelines/blob/vNext/Guide...
