Organising resource (URI) in REST API

Scenario 1

In my web application say for there is a screen for adding an employee to system. As soon as user tabs after entering name of the employee, it generates the employee code automatically (which is the next field) based on some logic and already present records in the database.

Now I want to expose rest API for this application so that third party devs can build on top of it. So, I will have a resource called as /Employee which will respond for GET, PUT and DELETE verbs. But when a client needs to autofill the code, which is a GET operation, it will be on what resource? Should I make a new resource /EmployeeCodeFor/{Name} or I should get it on /Employee/{Name}/GenerateCode? If I go with /Employee/{Name}/GenerateCode then what about my resource to GET, PUT and DELETE for Employee i.e. actually /Employee开发者_开发百科/{Id}?

Scenario 2

Here lets take the case of a stackoverflow post. So lets say the resource would be /Post/{Id}. In the same way as in the previous example it lists me possible duplicate question as soon as I tab out of the Title field.

Again on what URL I should get those possible duplicates?

I can't think of more scenarios just now. But many such kind of scenarios may come up in real life application development. How to implement them in RESTful way?

Update on scenario 1

Code and Id are two different fields. Id is primary key, code can be duplicate across departments just to illustrate. Also to generate a code, name should be provided first. So, if user types a name "FirstName LastName" then server might generate FL003 as code assuming that there are already two more employees with firstname starting from F and lastname starting from L in the said department. Department can be identified based on the logged in user.

---

One way to allow the server an opportunity to pre-fill a bunch of elements in a new resource is to do

POST /Employees
{with empty body}
=>
201 Created
Location: http://example.org/employee/3443

<Employee Id="3443">
   <Code>E1001</Code>
   <FirstName></FirstName>
   <LastName></LastName>
</Employee>

This gives the server one chance to provide default values. If you are looking for a more interactive way for the server to provide feedback during the input, I have another approach but it will take quite a bit more explaining.

---

Scenario 1

Let say your employee code is a unique identifier. In this case, to get it, you would allow the user to complete any field for the new employee and then make a POST. The server would generate the code and respond to the POST with a link to /Employee/{generated_code} which is the record for your newly created employee.

A GET on /Employee would return a list of all employees. A GET on /Employee/{a_code} will give you the employee detail.

Scenario 2

You could have some kind of query on the /Post collection like /Post?title_like={question_title}. A GET /Post?title_like=REST How to would return you a list of all questions containing "REST How to".