api-design

When starting with a package versioned at 1.0.0 in an API bundle, what should the new version be after adding a new interface to said package? The whitepaper makes this statement regarding compatibility: It should be obvious that binary compatibility plays an important role in backward compatibility. However, backward compatibility is also very dependent on the semantics. If the responsibility of an interface changes it could still be binary compatible but no longer be backward compatible. At the same time... 3.micro — A difference in the micro part does not signal any backward compatibility

I have a TensorFlow deep learning workflow in which I have a fairly simple data reading and feeding pipeline built using regular NumPy; but I see that TensorFlow offers a large number of functions for loading data and building a data pipeline. I wonder though what scenarios these target. It seems there are two: learning that involves very large real world datasets, and networks built with the with the high-level TensorFlow API . It seems that the benefits of using "reading" as opposed to "feeding" (e.g. functions such as tf.train.shuffle_batch , but even simple helpers like tf.one_hot ) apply

Having one big Swagger/OpenAPI YAML specification, how can I safely extract certain API endpoints and generate a new .yaml for them exclusively? It's easy to identify API endpoints from a certain level (like defined with one indent or more): paths: /users: ... - $ref: '#/requests/getUser' /repos: ... requests: getUser: ... I'd just copy all sections, except paths , into a new specs file. And then I'd copy certain paths subsections like /users: based on indents. In Python, with a regex. But is this direct method safe for the specs? Swagger Inspector lets you make API calls and then create the

So I have some resources in my API with foreign key relationships and these fk records (by design) cannot be created unless a POST is made to that specific resource first. I cannot create a Country by POSTing to Wine even though Country is a foreign key. the POST is going to /api/wine not /api/country In other words, if I send this payload to Wine resource: { id: 79, name: "Bordeaux", country: { id: 76, code: "FR", name: "France" }, year: "2005" } It will fail unless that country already exists. We cannot create the country from this POST because we are POSTing to the Wine resource and not

This is a spin-off question to query with filters Say my application is managing objects called workload, with the following fields. I want to expose a REST interface for user to query workloads by labels. "Workload": {"id":"test1", "labels":["A", "B", "C"]} "Workload": {"id":"test2", "labels":["A", "C", "D"]} "Workload": {"id":"test3", "labels":["A", "B", "D"]} Question : How do I design the REST endpoint so that it would support query workload with basic logic operations? Sample Query 2 : I want to GET all the workloads with label "A" or "B" but no "C" No clue how to do this sort of rest api

I'm designing an API Rest service that allows the user to upload a file to the server. I'm thinking this is a PUT request and it would go to server/resource/ID and have the file as base64 in the json request body. My question is regarding this ID. In my head, I'm passing the file to the server and the server should be in charge of storing that file and generating a unique ID to retrieve it later, and then return this ID to the client with an ok status. So I'm thinking about doing that, sending it to server/resource, without the ID, but is this ok or is it bad design? Tatsuyuki Ishi No. PUT