![]() ![]() One area where GraphQL excels is to make monitoring field usage incredibly easy at a technical level. REST is about evolvability, so don’t blame it for the bad habits of us RESTish people.Īlthough GraphQL and REST can (and should) version via evolution just as easily, GraphQL really helps API developers out when it comes to deprecations. The suggested approach is to add new fields and deprecate old ones, which is a concept well known in REST as evolution.ĭeprecating, communicating to third-parties, monitoring usage, and removing at an acceptable time, is exactly what many REST APIs have been doing forever. One false advertised benefit of GraphQL I’ve seen suggested (in quite a few locations) is that you "never have to version anything." ![]() A REST API can do anything, not just send fields backwards and forwards - even if that is how REST is often used. Some would say that REST handling CRUD and arbitrary stuff is confusing, but this is a core tenant of what makes REST so useful. This is one area where REST holds strong. Another approach is to upload directly to Amazon S3, forcing a dependency on clients and potentially letting your tokens leak, or… use multipart uploads, which are a super hacky approach that depends on if the server and various clients can even support it. Some will argue that this is more "clean", and it is, it’s very clean, but being forced to create another service is overkill for smaller images, especially early on. This is the approach you are forced to take with GraphQL, because you can only speak to GraphQL in terms of fields: POST /graphql HTTP/1.1 If we were talking about uploading videos or other large files, I would (as this article suggests) switch to another approach and have a dedicated service which handles the upload, leaving the main API to only accept metadata title, description, tags, etc. Generally the APIs I have worked on have enjoyed both, which is super handy as iOS often sends photos directly from local files, and web clients often send a URL to the user’s Facebook display picture. ![]() Leveraging a cool part of HTTP (and therefore REST), API developers can support application/json requests on the same endpoint to handle the upload slightly differently, and offer URL-based uploads too: POST /avatars HTTP/1.1 Uploading an image in the HTTP body can look a little something like this: POST /avatars HTTP/1.1 One of the most common tasks REST APIs provide is CRUD via JSON, but it can do plenty more than that, such as file uploads. Let’s dig in! Is the API More Than Data Transfer? GraphQL comes out stronger in some areas, REST in others, and sometimes they’re both kinda terrible. Don’t get mad that a lot of the sections say "it depends", because the winner in each section really depends on what your API is doing, and how. This article will not attempt to point out a winner, but we’re going to look at a few areas where the two differ. If your API is not using hypermedia controls, then GraphQL could be a more relevant approach, because you weren’t really using REST anyway. When utilizing HTTP, REST can leverage HTTP content-types, caching, status codes, etc., whereas GraphQL invents its own conventions.Īnother main focus for REST is hypermedia controls (a.k.a HATEOAS), which lets a well designed client run around an API like a human runs around the Internet starting with a search for "How to complete my tax returns", reading a perfectly relevant article, and after a few clicks ending up on BuzzFeed article about Miley Cyrus throwing Liam Hemsworth a "Weed-Themed" birthday party. One of the main tenants of REST is to utilize the uniform interface of the protocols it exists in. GraphQL is a query language, specification, and collection of tools, designed to operate over a single endpoint via HTTP, optimizing for performance and flexibility. The focus is on making APIs last for decades, instead of optimizing for performance. REST is an architectural concept for network-based software, has no official set of tools, has no specification, doesn’t care if you use HTTP, AMQP, etc., and is designed to decouple an API from the client. GraphQL is dope if used for the right thing. ![]() You can definitely use both at the same time.GraphQL isn’t a magic bullet, nor is it "better".This article aims to cover a few notable differences, and make the following points: GraphQL is a newer concept, being released by Facebook publicly in 2015, whereas REST was a dissertation published by Roy Fielding in 2000, popularized by companies like Twitter (quite inaccurately) in 2006. GraphQL is incorrectly considered by some to be a "replacement" to REST. A few months back I wrote a comparison between RPC and REST for Smashing Magazine, and now I want to talk about the differences between REST and GraphQL: the new kid on the block. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |