![]() ![]() That said, I don't think this pattern is necessarily bad. Adhering to common conventions and expectations simplifies things and helps avoid mistakes. ![]() Inconsistent with the rest of the world.API documentation, accessibility, and discoverability were important to us. Swagger (our API documentation tool) would have no intuitive way to document the structure of this API.Pro: Saved half a line of code in the API implementation In our case, I found the tradeoffs were simply: He was adding a new API endpoint and wanted to pass in a complex JSON object into the query string instead of separate parameters.Įxactly what the pros and cons are will depend on your specific product needs, architecture, team structure, and other factors. I went through almost the same analysis with a former coworker. Is this a bad/good idea? I see advantages and disadvantages, but I'm trying to look past my personal bias. Disregarding that, the basic question is: And I realize that the structure of the JSON object for querying would have to be altered, as it does not account for some things. We are in JavaScript on both client and server, so parsing the JSON object is not a difficult task. Which, after encoding, looks something like this as a URL (sorry if I messed up the encoding, I made this up as an example): GET /api/v1/widgets?filters=&pagination=%7B%22page%22:%222%22,%22pagesize%22:%2225%22,%22sort%22:,%22sortdirection%22:%7D This would result in SQL something like SELECT I'm building an API endpoint for a UI grid to search, filter, and display a list of domain objects, let's call them "widgets." In the past, I would have built this with a list of named query string parameters, like this: GET /api/v1/widgets?type=2&name=what&from=&to=&pagesize=25&page=2&sort=name,-createdate ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |